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Préface 


C'est quoi ces deux titres? 


Le livre a été appelé "Reverse Engineering for Beginners" en 2014-2018, mais j'ai 
toujours suspecté que ca rendait son audience trop réduite. 


Les gens de l'infosec connaissent le "reverse engineering", mais j'ai rarement en- 
tendu le mot "assembleur" de leur part. 


De méme, le terme "reverse engineering" est quelque peu cryptique pour une au- 
dience générale de programmeurs, mais qui ont des connaissances à propos de 
l'"assembleur". 


En juillet 2018, à titre d'expérience, j'ai changé le titre en "Assembly Language for 
Beginners” et publié le lien sur le site Hacker News’, et le livre a été plutôt bien 
accueilli. 


Donc, c'est ainsi que le livre a maintenant deux titres. 


Toutefois, j'ai changé le second titre à "Understanding Assembly Language", car 
quelqu'un a déjà écrit le livre "Assembly Language for Beginners". De méme, des 
gens disent que “for Beginners" sonne sarcastique pour un livre de ~1000 pages. 


Les deux livres différent seulement par le titre, le nom du fichier (UAL-XX.pdf versus 
RE4B-XX.pdf), l'URL et quelques-une des première pages. 


À propos de la rétro-ingénierie 


Il existe plusieurs définitions pour l'expression «ingénierie inverse ou rétro-ingénierie 
reverse engineering » : 


1) L'ingénierie inverse de logiciels : examiner des programmes compilés; 


2) Le balayage des structures en 3D et la manipulation numérique nécessaire afin 
de les reproduire; 


3) Recréer une structure de base de données. 


Ce livre concerne la première définition. 


Prérequis 


Connaissance basique du C LP”. Il est recommandé de lire: 12.1.3 on page 1315. 


Exercices et táches 


... ont été déplacés sur un site différent : http: //challenges. re. 


Shttps://news.ycombinator.com/item?id=17549050 
"Langage de programmation 
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Éloges de ce livre 
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Universités 
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mini-FAQ 
Q: Est-ce que ce livre est plus simple/facile que les autres? 
R: Non, c'est à peu prés le méme niveau que les autres livres sur ce sujet. 


Q: J'ai trop peur de commencer à lire ce livre, il fait plus de 1000 pages. "...for Be- 
ginners" dans le nom sonne un peu sarcastique. 


R: Toutes sortes de listings constituent le gros de ce livre. Le livre est en effet pour 
les débutants, il manque (encore) beaucoup de choses. 


Q: Quels sont les pré-requis nécessaires avant de lire ce livre? 
R: Une compréhension de base du C/C++ serait l'idéal. 


Q: Dois-je apprendre x86/x64/ARM et MIPS en méme temps? N'est-ce pas un peu 
trop ? 


R: Je pense que les débutants peuvent seulement lire les parties x86/x64, tout en 
passant/feuilletant celles ARM/MIPS. 


Q: Puis-je acheter une version papier du livre en russe / anglais ? 


R: Malheureusement non, aucune maison d'édition n'a été intéressée pour publier 
une version en russe ou en anglais du livre jusqu'à présent. Cependant, vous pou- 
vez demander à votre imprimerie préférée de l'imprimer et de le relier. https:// 
yurichev.com/news/20200222 printed RE4B/. 


Q: Y a-il une version ePub/Mobi ? 


R: Le livre dépend majoritairement de TeX/LaTeX, il n'est donc pas évident de le 
convertir en version ePub/Mobi. 


Q: Pourquoi devrait-on apprendre l'assembleur de nos jours? 


R: A moins d'être un développeur d’OS?°, vous n'aurez probablement pas besoin 
d'écrire en assembleur—les derniers compilateurs (ceux de notre décennie) sont 
meilleurs que les étres humains en terme d'optimisation. 2°. 


De plus, les derniers CPU?/s sont des appareils complexes et la connaissance de 
l'assembleur n'aide pas vraiment à comprendre leurs mécanismes internes. 


Cela dit, il existe au moins deux domaines dans lesquels une bonne connaissance 
de l'assembleur peut étre utile : Tout d'abord, pour de la recherche en sécurité ou 
sur des malwares. C'est également un bon moyen de comprendre un code compilé 
lorsqu'on le debug. Ce livre est donc destiné à ceux qui veulent comprendre l'assem- 
bleur plutót que d'écrire en assembleur, ce qui explique pourquoi il y a de nombreux 
exemples de résultats issus de compilateurs dans ce livre. 


Q: J'ai cliqué sur un lien dans le document PDF, comment puis-je retourner en ar- 
rière ? 


R: Dans Adobe Acrobat Reader, appuyez sur Alt + Fléche gauche. Dans Evince, ap- 
puyez sur le bouton “<”. 


?5Systéme d'exploitation (Operating System) 
26Un trés bon article à ce sujet : [Agner Fog, The microarchitecture of Intel, AMD and VIA CPUs, (2016)] 
?! Central Processing Unit 


XX 


Q: Puis-je imprimer ce livre / l'utiliser pour de l'enseignement? 


R: Bien súr! C'est la raison pour laquelle le livre est sous licence Creative Commons 
(CC BY-SA 4.0). 


Q: Pourquoi ce livre est-il gratuit ? Vous avez fait du bon boulot. C'est suspect, comme 
nombre de choses gratuites. 


R: D'aprés ma propre expérience, les auteurs d'ouvrages techniques font cela pour 
l'auto-publicité. Il n'est pas possible de se faire beaucoup d'argent d'une telle ma- 
nière. 

Q: Comment trouver du travail dans le domaine de la rétro-ingénierie ? 


R: Il existe des sujets d'embauche qui apparaissent de temps en temps sur Reddit, 
dédiés à la rétro-ingénierie (cf. reverse engineering ou RE)?*. Jetez un ceil ici. 


Un sujet d'embauche quelque peu lié peut étre trouvé dans le subreddit «netsec ». 
Q: J'ai une question... 


R: Envoyez-la moi par email (my emails). 


À propos de la traduction en Coréen 


En Janvier 2015, la maison d'édition Acorn (www.acornpub.co.kr) en Corée du Sud 
a réalisé un énorme travail en traduisant et en publiant mon livre (dans son état en 
Aoút 2014) en Coréen. 


Il est désormais disponible sur leur site web. 


Le traducteur est Byungho Min (twitter/tais9). L'illustration de couverture a été réa- 
lisée l'artiste, Andy Nechaevsky, un ami de l'auteur: facebook/andydinka. Ils dé- 
tiennent également les droits d'auteurs sur la traduction coréenne. 


Donc si vous souhaitez avoir un livre réel en coréen sur votre étagére et que vous 
souhaitez soutenir ce travail, il est désormais disponible à l'achat. 


Á propos de la traduction en Farsi/Perse 


En 2016, ce livre a été traduit par Mohsen Mostafa Jokar (qui est aussi connu dans la 
communauté iranienne pour sa traduction du manuel de Radare?”). Il est disponible 
sur le site web de l'éditeur”? (Pendare Pars). 


Extrait de 40 pages: https://beginners.re/farsi.pdf. 


Enregistrement du livre à la Bibliothèque Nationale d'Iran: http://opac.nlai.ir/ 
opac-prod/bibliographic/4473995. 


28reddit.com/r/ReverseEngineering/ 
29http://rada. re/get/radare2book- persian. pdf 
30http://goo.gl/2Tzx0H 
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Á propos de la traduction en Chinois 


En avril 2017, la traduction en Chinois a été terminée par Chinese PTPress. Ils sont 
également les détenteurs des droits de la traduction en Chinois. 


La version chinoise est disponible à l'achat ici: http://www.epubit.com.cn/book/ 
details/4174. Une revue partielle et l'historique de la traduction peut étre trouvé 
ici: http://www.cptoday.cn/news/detail/3155. 


Le traducteur principal est Archer, à qui je dois beaucoup. ll a été trés méticuleux 
(dans le bon sens du terme) et a signalé la plupart des erreurs et bugs connus, ce 
qui est trés important dans le genre de littérature de ce livre. Je recommanderais 
ses services à tout autre auteur! 


Les gens de Antiy Labs ont aussi aidé pour la traduction. Voici la préface écrite par 
eux. 


Chapitre 1 


Pattern de code 


1.1 La méthode 


Lorsque j'ai commencé à apprendre le C, et plus tard, le C++, j'ai pris l'habitude 
d'écrire des petits morceaux de code, de les compiler et de regarder le langage 
d'assemblage généré. Cela m'a permis de comprendre facilement ce qui se passe 
dans le code que j'écris. !. Je l'ai fait si souvent que la relation entre le code C++ 
et ce que le compilateur produit a été imprimée profondément dans mon esprit. Ca 
m'est facile d'imaginer immédiatement l'allure de la fonction et du code C. Peut-étre 
que cette méthode pourrait étre utile à d'autres. 


Parfois, des anciens compilateurs sont utilisés, afin d'obtenir des extraits de code le 
plus court (ou le plus simple) possible. 


À propos, il y a un bon site oü vous pouvez faire la méme chose, avec de nombreux 
compilateurs, au lieu de les installer sur votre systéme. Vous pouvez également 
l'utiliser: https://godbolt.org/. 


Exercices 


Lorsque j'étudiais le langage d'assemblage, j'ai souvent compilé des petites fonc- 
tions en C et les ai ensuite récrites peu à peu en assembleur, en essayant d'obtenir 
un code aussi concis que possible. Cela n'en vaut probablement plus la peine aujour- 
d'hui, car il est difficile de se mesurer aux derniers compilateurs en terme d'efficacité. 
Cela reste par contre un excellent moyen d'approfondir ses connaissances de l'as- 
sembleur. N'hésitez pas à prendre n'importe quel code assembleur de ce livre et à 
essayer de le rendre plus court. Toutefois, n'oubliez pas de tester ce que vous aurez 
écrit. 


1En fait, je le fais encore cela lorsque je ne comprends pas ce qu'un morceau de code fait. Exemple 
récent de 2019: p += p+(i&1)+2; tiré de "SATOW" solveur SAT par D.Knuth. 


2 
Niveau d'optimisation et information de débogage 


Le code source peut étre compilé par différents compilateurs, avec des niveaux d'op- 
timisation variés. Un compilateur en a typiquement trois, oü le niveau O désactive 
l'optimisation. L'optimisation peut se faire en ciblant la taille du code ou la vitesse 
d'exécution. Un compilateur sans optimisation est plus rapide et produit un code 
plus compréhensible (quoique verbeux), alors qu'un compilateur avec optimisation 
est plus lent et essaye de produire un code qui s'exécute plus vite (mais pas forcé- 
ment plus compact). En plus des niveaux d'optimisation, un compilateur peut inclure 
dans le fichier généré des informations de débogage, qui produit un code facilitant 
le débogage. Une des caractéristiques importante du code de ‘debug’, est qu'il peut 
contenir des liens entre chaque ligne du code source et les adresses du code machine 
associé. D'un autre cóté, l'optimisation des compilateurs tend à générer du code oü 
des lignes du code source sont modifiées, et méme parfois absentes du code ma- 
chine résultant. Les rétro-ingénieurs peuvent rencontrer n'importe quelle version, 
simplement parce que certains développeurs mettent les options d'optimisation, et 
d'autres pas. Pour cette raison, et lorsque c'est possible, nous allons essayer de tra- 
vailler sur des exemples avec les versions de débogage et finale du code présenté 
dans ce livre. 


1.2 Quelques bases 


1.2.1 Une courte introduction sur le CPU 


Le CPU est le systéme qui exécute le code machine que constitue le programme. 
Un court glossaire: 


Instruction :Une commande CPU primitive. Les exemples les plus simples incluent: 
déplacement de données entre les registres, travail avec la mémoire et les 
opérations arithmétiques primitives. Généralement, chaque CPU a son propre 
jeu d'instructions (ISA). 


Code machine : Code que le CPU exécute directement. Chaque instruction est 
codée sur plusieurs octets. 


Langage d'assemblage : Code mnémotechnique et quelques extensions comme 
les macros qui facilitent la vie du programmeur. 


Registre CPU : Chaque CPU a un ensemble de registres d'intérét général (GPR?). 
x 8 pour x86, « 16 pour x86-64, x 16 pour ARM. Le moyen le plus simple de com- 
prendre un registre est de le voir comme une variable temporaire non-typée. 
Imaginez que vous travaillez avec un LP de haut niveau et que vous pouvez 
utiliser uniquement huit variables de 32-bit (ou de 64-bit). C'est malgré tout 
possible de faire beaucoup de choses en les utilisant! 


On pourrait se demander pourquoi il y a besoin d'une différence entre le code ma- 
chine et un LP. La réponse est que les humains et les CPUs ne sont pas semblables— 
c'est beaucoup plus simple pour les humains d'utiliser un LP de haut niveau comme 
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C/C++, Java, Python, etc., mais c'est plus simple pour un CPU d'utiliser un niveau 
d'abstraction de beaucoup plus bas niveau. Peut-étre qu'il serait possible d'inventer 
un CPU qui puisse exécuter du code d'un LP de haut niveau, mais il serait beaucoup 
plus complexe que les CPUs que nous connaissons aujourd'hui. D'une maniére simi- 
laire, c'est moins facile pour les humains d'écrire en langage d'assemblage à cause 
de son bas niveau et de la difficulté d'écrire sans faire un nombre énorme de fautes 
agacantes. Le programme qui convertit d'un LP haut niveau vers l'assemblage est 
appelé un compilateur. 


Quelques mots sur les différents ISAs 


Le jeu d'instructions ISA x86 a toujours été avec des instructions de taille variable. 
Donc quand l'époque du 64-bit arriva, les extensions x64 n'ont pas impacté le ISA 
trés significativement. En fait, le ISA x86 contient toujours beaucoup d'instructions 
apparues pour la premiére fois dans un CPU 8086 16-bit, et que l'on trouve encore 
dans beaucoup de CPUs aujourd'hui. ARM est un CPU RISC? conçu avec l'idée d'ins- 
tructions de taille fixe, ce qui présentait quelques avantages dans le passé. Au tout 
début, toutes les instructions ARM étaient codés sur 4 octets^. C'est maintenant 
connu comme le «ARM mode ». Ensuite ils sont arrivés à la conclusion que ce n'était 
pas aussi économique qu'ils l'avaient imaginé sur le principe. En réalité, la majorité 
des instructions CPU utilisées? dans le monde réel peuvent étre encodées en utilisant 
moins d'informations. Ils ont par conséquent ajouté un autre ISA, appelé Thumb, où 
chaque instruction était encodée sur seulement 2 octets. C'est maintenant connu 
comme le «Thumb mode ». Cependant, toutes les instructions ne peuvent étre en- 
codées sur seulement 2 octets, donc les instructions Thumb sont un peu limitées. 
On peut noter que le code compilé pour le mode ARM et pour le mode Thumb peut, 
évidemment, coexister dans un seul programme. Les créateurs de ARM pensérent 
que Thumb pourrait étre étendu, donnant naissance à Thumb-2, qui apparut dans 
ARMv7. Thumb-2 utilise toujours des instructions de 2 octets, mais a de nouvelles 
instructions dont la taille est de 4 octets. Une erreur couramment répandue est que 
Thumb-2 est un mélange de ARM et Thumb. C'est incorrect. Plutót, Thumb-2 fut éten- 
du pour supporter totalement toutes les caractéristiques du processeur afin qu'il 
puisse rivaliser avec le mode ARM—un objectif qui a été clairement réussi, puisque 
la majorité des applications pour iPod/iPhone/iPad est compilée pour le jeu d'instruc- 
tions de Thumb-2 (il est vrai que c'est largement dú au fait que Xcode le faisait par 
défaut). Plus tard, le ARM 64-bit sortit. Ce ISA a des instructions de 4 octets, et enle- 
vait le besoin d'un mode Thumb supplémentaire. Cependant, les prérequis de 64-bit 
affectérent le ISA, résultant maintenant au fait que nous avons trois jeux d'instruc- 
tions ARM: ARM mode, Thumb mode (incluant Thumb-2) et ARM64. Ces ISAs s'inter- 
sectent partiellement, mais on peut dire que ce sont des ISAs différents, plutót que 
des variantes du méme. Par conséquent, nous essayerons d'ajouter des fragments 
de code dans les trois ISAs de ARM dans ce livre. Il y a, d'ailleurs, bien d'autres ISAs 
RISC avec des instructions de taille fixe de 32-bit, comme MIPS, PowerPC et Alpha 
AXP. 
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^D'ailleurs, les instructions de taille fixe sont pratiques parce qu'il est possible de calculer l'instruction 
suivante (ou précédente) sans effort. Cette caractéristique sera discutée dans la section de l'opérateur 
switch() (1.21.2 on page 227). 

5Ce sont MOV/PUSH/CALL/Jcc 


1.2.2 Systémes de numération 


Nowadays octal numbers seem to be used 
for exactly one purpose—file permissions on 
POSIX systems—but hexadecimal numbers 
are widely used to emphasize the bit pattern 
of a number over its numeric value. 


Alan A. A. Donovan, Brian W. Kernighan — 
The Go Programming Language 


Les Hommes ont probablement pris l'habitude d'utiliser la numérotation décimale 
parce qu'ils ont 10 doigts. Néanmoins, le nombre 10 n'a pas de signification particu- 
lière en science et en mathématiques. En électronique, le système de numérotation 
est le binaire : O pour l'absence de courant dans un fil et 1 s'il y en a. 10 en binaire 
est 2 en décimal; 100 en binaire est 4 en décimal et ainsi de suite. 


Si le systéme de numération a 10 chiffres, il est en base 10. Le systéme binaire est 
en base 2. 


Choses importantes à retenir: 


1) Un nombre est un nombre, tandis qu'un chiffre est un élément d'un systéme 
d'écriture et est généralement un caractére 


2) Un nombre ne change pas lorsqu'on le convertit dans une autre base; seule sa 
représentation écrite change (et donc la façon de le représenter en RAM). 


1.2.3 Conversion d'une base à une autre 


La notation positionnelle est utilisée dans presque tous les systémes de numération, 
cela signifie qu'un chiffre a un poids dépendant de sa position dans la représentation 
du nombre. Si 2 se situe le plus à droite, c'est 2. S'il est placé un chiffre avant celui 
le plus à droite, c'est 20. 


Que représente 1234? 
10?-1+ 102-2 4-101 -3-- 1-4 = 1234 ou 1000-1 4- 100-2 -- 10-3-- 4 = 1234 


De méme pour les nombres binaires, mais la base est 2 au lieu de 10. Que représente 
0b101011? 


25.1--2*.0-E 23.1: 22.0 -21.14- 22.1 = 43 ou 32-1+16-04+8-1+4-0+2-14+1=43 


Il existe aussi la notation non-positionnelle comme la numération romaine’. Peut- 
étre que l'humanité a choisi le systéme de numération positionnelle parce qu'il était 
plus simple pour les opérations basiques (addition, multiplication, etc.) à la main sur 
papier. 


En effet, les nombres binaires peuvent étre ajoutés, soustraits et ainsi de suite de la 
méme manière que c'est enseigné à l'école, mais seulement 2 chiffres sont dispo- 
nibles. 


SRandom-Access Memory 
7À propos de l'évolution du systéme de numération, voir [Donald E. Knuth, The Art of Computer Pro- 
gramming, Volume 2, 3rd ed., (1997), 195-213.] 
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Les nombres binaires sont volumineux lorsqu'ils sont représentés dans le code source 
et les dumps, c'est pourquoi le systéme hexadécimal peut étre utilisé. La base hexa- 
décimale utilise les nombres 0..9 et aussi 6 caracteres latins : A..F. Chaque chiffre 
hexadécimal prend 4 bits ou 4 chiffres binaires, donc c'est trés simple de conver- 
tir un nombre binaire vers l'hexadécimal et inversement, méme manuellement, de 
téte. 


hexadécimal | binaire | décimal 
0 0000 0 
1 0001 1 
2 0010 2 
3 0011 3 
4 0100 4 
5 0101 5 
6 0110 6 
7 0111 7 
8 1000 8 
9 1001 9 
A 1010 10 
B 1011 11 
C 1100 12 
D 1101 13 
E 1110 14 
F 1111 15 


Comment savoir quelle est la base utilisée dans un cas particulier? 


Les nombres décimaux sont d'ordinaire écrits tels quels, i.e, 1234. Certains assem- 
bleurs permettent d'accentuer la base décimale, et les nombres peuvent alors s'écrire 
avec le suffixe "d" : 1234d. 


Les nombres binaires sont parfois préfixés avec "Ob" : 05100110111 (GCC a une 
extension de langage non-standard pour ca ?). Il y a aussi un autre moyen : le suffixe 
"bp", par exemple : 100110111b. J'essaierai de garder le préfixe "Ob" tout le long du 
livre pour les nombres binaires. 


Les nombres hexadécimaux sont préfixés avec "Ox" en C/C++ et autres LPs : 0x1234ABCD. 
Ou ils ont le suffixe "h" : 1234ABCDh - c'est une maniére commune de les représen- 

ter dans les assembleurs et les débogueurs. Si le nombre commence par un A..F, 

un O est ajouté au début : OABCDEFh. Il y avait une convention répandue à l'ère 

des ordinateurs personnels 8-bit, utilisant le préfixe $, comme $ABCD. J'essaierai de 
garder le préfixe "Ox" tout le long du livre pour les nombres hexadécimaux. 


Faut-il apprendre à convertir les nombres de téte? La table des nombres hexadéci- 
maux de 1 chiffre peut facilement étre mémorisée. Pour les nombres plus gros, ce 
n'est pas la peine de se tourmenter. 


8GNU Compiler Collection 
9https://gcc.gnu.org/onlinedocs/gcc/Binary- constants.html 
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Peut-être que les nombres hexadécimaux les plus visibles sont dans les URLs. C'est 
la facon d'encoder les caractéres non-Latin. Par exemple: https://en.wiktionary. 
org/wiki/na%C3%AFvet%C3%A9 est l'URL de l'article de Wiktionary à propos du mot 
«naïveté ». 


Base octale 


Un autre systéme de numération a été largement utilisé en informatique est la repré- 
sentation octale. Elle comprend 8 chiffres (0..7), et chacun occupe 3 bits, donc c'est 
facile de convertir un nombre d'une base à l'autre. Il est maintenant remplacé par 
le systéme hexadécimal quasiment partout mais, chose surprenante, il y a encore 
une commande sur *NIX, utilisée par beaucoup de personnes, qui a un nombre octal 
comme argument : chmod. 


Comme beaucoup d'utilisateurs *NIX le savent, l'argument de chmod peut étre un 
nombre à 3 chiffres. Le premier correspond aux droits du propriétaire du fichier, le 
second correspond aux droits pour le groupe (auquel le fichier appartient), le troi- 
siéme est pour tous les autres. Et chaque chiffre peut étre représenté en binaire: 


décimal | binaire | signification 
7 111 rwx 

6 110 rw- 

5 101 r-x 

4 100 r-- 

3 011 -WX 

2 010 -W- 

1 001 --X 

0 000 --- 


Ainsi chaque bit correspond à un droit: lecture (r) / écriture (w) / exécution (x). 


L'importance de chmod est que le nombre entier en argument peut étre écrit comme 
un nombre octal. Prenons par exemple, 644. Quand vous tapez chmod 644 file, 
vous définissez les droits de lecture/écriture pour le propriétaire, les droits de lecture 
pour le groupe et encore les droits de lecture pour tous les autres. Convertissons le 
nombre octal 644 en binaire, ca donne 110100100, ou (par groupe de 3 bits) 110 
100 100. 


Maintenant que nous savons que chaque triplet sert à décrire les permissions pour 
le propriétaire/groupe/autres : le premier est rw-, le second est r- - et le troisième 
est r--. 


Le systéme de numération octal était aussi populaire sur les vieux ordinateurs comme 
le PDP-8 parce que les mots pouvaient étre de 12, 24 ou de 36 bits et ces nombres 
sont divisibles par 3, donc la représentation octale était naturelle dans cet environne- 
ment. Aujourd'hui, tous les ordinateurs populaires utilisent des mots/taille d'adresse 
de 16, 32 ou de 64 bits et ces nombres sont divisibles par 4, donc la représentation 
hexadécimale était plus naturelle ici. 


10Uniform Resource Locator 
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Le systéme de numération octal est supporté par tous les compilateurs C/C++ stan- 
dards. C'est parfois une source de confusion parce que les nombres octaux sont 
notés avec un zéro au début. Par exemple, 0377 est 255. Et parfois, vous faites une 
faute de frappe et écrivez "09" au lieu de 9, et le compilateur renvoie une erreur. 
GCC peut renvoyer quelque chose comme ca: 
erreur: chiffre 9 invalide dans la constante en base 8. 


De méme, le système octal est assez populaire en Java. Lorsque IDA?! affiche des 
chaínes Java avec des caractéres non-imprimables, ils sont encodés dans le systéme 
octal au lieu d'hexadécimal. Le décompilateur Java JAD se comporte de la méme 
facon. 


Divisibilité 
Quand vous voyez un nombre décimal comme 120, vous en déduisez immédiate- 


ment qu'il est divisible par 10, parce que le dernier chiffre est zéro. De la méme 
facon, 123400 est divisible par 100 parce que les deux derniers chiffres sont zéros. 


Pareillement, le nombre hexadécimal 0x1230 est divisible par 0x10 (ou 16), 0x123000 
est divisible par 0x1000 (ou 4096), etc. 


Un nombre binaire 061000101000 est divisible par 0b1000 (8), etc. 


Cette propriété peut étre souvent utilisée pour déterminer rapidement si l'adresse 
ou la taille d'un bloc mémoire correspond à une limite. Par exemple, les sections 
dans les fichiers PE!? commencent quasiment toujours à une adresse finissant par 
3 zéros hexadécimaux: 0x41000, 0x10001000, etc. La raison sous-jacente est que 
la plupart des sections PE sont alignées sur une limite de 0x1000 (4096) octets. 


Arithmétique multi-précision et base 


L'arithmétique multi-précision utilise des nombres trés grands et chacun peut étre 
stocké sur plusieurs octets. Par exemple, les clés RSA, tant publique que privée, 
utilisent jusqu'à 4096 bits et parfois plus encore. 


Dans [Donald E. Knuth, The Art of Computer Programming, Volume 2, 3rd ed., (1997), 
265] nous trouvons l'idée suivante: quand vous stockez un nombre multi-précision 
dans plusieurs octets, le nombre complet peut étre représenté dans une base de 
25 — 256, et chacun des chiffres correspond à un octet. De la méme manière, si 
vous sauvegardez un nombre multi-précision sur plusieurs entiers de 32 bits, chaque 
chiffre est associé à l'emplacement de 32 bits et vous pouvez penser à ce nombre 
comme étant stocké dans une base 2*?. 


Comment prononcer les nombres non-décimaux 


Les nombres dans une base non décimale sont généralement prononcés un chiffre à 


la fois : "un-zéro-zéro-un-un-...". Les mots comme "dix", "mille", etc, ne sont géné- 
ralement pas prononcés, pour éviter d'étre confondus avec ceux en base décimale. 
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Nombres a virgule flottante 


Pour distinguer les nombres à virgule flottante des entiers, ils sont souvent écrits 
avec avec un “.0” à la fin, comme 0.0, 123.0, etc. 


1.3 Fonction vide 


La fonction la plus simple possible est sans doute celle qui ne fait rien: 


Listing 1.1 : Code C/C++ 


void f() 
1 


}; 


return; 


Compilons-la! 


1.3.1 x86 
Voici ce que les compilateurs GCC et MSVC produisent sur une plateforme x86: 


Listing 1.2 : GCC/MSVC avec optimisation (résultat en sortie de l'assembleur) 


ret 


Il y a juste une instruction: RET, qui détourne l'exécution vers l'appelant. 


1.3.2 ARM 

Listing 1.3 : avec optimisation Keil 6/2013 (Mode ARM) ASM Output 
f PROC 

BX lr 

ENDP 


L'adresse de retour n'est pas stockée sur la pile locale avec l'ISA ARM, mais dans le 
"link register" (registre de lien), donc l'instruction BX LR force le flux d'exécution à 
sauter à cette adresse—renvoyant effectivement l'exécution vers l'appelant. 


1.3.3 MIPS 


Il y a deux conventions de nommage utilisées dans le monde MIPS pour nommer les 
registres: par numéro (de $0 à $31) ou par un pseudo-nom ($VO, $AO, etc.). 


La sortie de l'assembleur GCC ci-dessous liste les registres par numéro: 


Listing 1.4 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


J $31 
nop 


...tandis qu'IDA le fait—avec les pseudo noms: 


Listing 1.5 : GCC 4.4.5 avec optimisation (IDA) 


j $ra 
nop 


La premiére instruction est l'instruction de saut (J ou JR) qui détourne le flux d'exé- 
cution vers l'appelant, sautant à l'adresse dans le registre $31 (ou $RA). 


Ce registre est similaire à LR! en ARM. 


La seconde instruction est NOP‘, qui ne fait rien. Nous pouvons l'ignorer pour l'ins- 
tant. 


Une note à propos des instructions MIPS et des noms de registres 


Les registres et les noms des instructions dans le monde de MIPS sont traditionnel- 
lement écrits en minuscules. Cependant, dans un souci d'homogénéité, nous allons 
continuer d'utiliser les lettres majuscules, étant donné que c'est la convention suivie 
par tous les autres ISAs présentés dans ce livre. 


1.3.4 Fonctions vides en pratique 


Bien que les fonctions vides soient inutiles, elles sont assez fréquentes dans le code 
bas niveau. 


Tout d'abord, les fonctions de débogage sont assez populaires, comme celle-ci: 


Listing 1.6 : Code C/C++ 


void dbg print (const char *fmt, ...) 


1 
#ifdef DEBUG 
// open log file 
// write to log file 
// close log file 
#endif 
$; 


void some function() 


t 


dbg print ("we did something Nn"); 


}; 


Dans une compilation en non-debug (e.g., “release”), DEBUG n'est pas défini, donc 
la fonction dbg print(), bien qu'elle soit appelée pendant l'exécution, sera vide. 


13Link Register 
1^No Operation 
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Un autre moyen de protection logicielle est de faire plusieurs compilations: une pour 
les clients, une de démonstration. La compilation de démonstration peut omettre 
certaines fonctions importantes, comme ici: 


Listing 1.7 : Code C/C++ 


void save file () 


1 
#ifndef DEMO 
// a real saving code 
#endif 
$; 


La fonction save file() peut étre appelée lorsque l'utilisateur clique sur le menu 
Fichier->Enregistrer. La version de démo peut étre livrée avec cet item du menu 
désactivé, mais méme si un logiciel cracker pourra l'activer, une fonction vide sans 
code utile sera appelée. 


IDA signale de telles fonctions avec des noms comme nullsub 00, nullsub 01, etc. 


1.4 Valeur de retour 


Une autre fonction simple est celle qui retourne juste une valeur constante: 
La voici: 


Listing 1.8 : Code C/C++ 


int f() 
{ 


}; 


return 123; 


Compilons la! 


1.4.1 x86 
Voici ce que les compilateurs GCC et MSVC produisent sur une plateforme x86: 


Listing 1.9 : GCC/MSVC avec optimisation (résultat en sortie de l’assembleur) 


mov eax, 123 
ret 


Il y a juste deux instructions: la première place la valeur 123 dans le registre EAX, qui 
est par convention le registre utilisé pour stocker la valeur renvoyée d'une fonction 
et la seconde est RET, qui retourne l'exécution vers l'appelant. 


L'appelant prendra le résultat de cette fonction dans le registre EAX. 
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1.4.2 ARM 
Il y a quelques différences sur la platforme ARM: 


Listing 1.10 : avec optimisation Keil 6/2013 (Mode ARM) ASM Output 


f PROC 
MOV ro, *0x7b ; 123 
BX lr 
ENDP 


ARM utilise le registre RO pour renvoyer le résultat d'une fonction, donc 123 est copié 
dans RO. 


Il est a noter que l'instruction MOV est trompeuse pour les plateformes x86 et ARM 
ISAs. 


La donnée n'est en réalité pas déplacée (moved) mais copiée. 


1.4.3 MIPS 
La sortie de l'assembleur GCC ci-dessous indique les registres par numéro: 


Listing 1.11 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


j $31 
li $2,123 # Ox7b 


...tandis qu'IDA le fait—avec les pseudo noms: 


Listing 1.12 : GCC 4.4.5 avec optimisation (IDA) 


jr $ra 
li $v0, Ox7B 


Le registre $2 (ou $VO) est utilisé pour stocker la valeur de retour de la fonction. LI 
signifie "Load Immediate" et est l'équivalent MIPS de MOV. 


L'autre instruction est l'instruction de saut (J ou JR) qui retourne le flux d'exécution 
vers l'appelant. 


Vous pouvez vous demander pourquoi la position de l'instruction d'affectation de va- 
leur immédiate (LI) et l'instruction de saut (J ou JR) sont échangées. Ceci est dú à une 
fonctionnalité du RISC appelée "branch delay slot" (slot de délai de branchement). 


La raison de cela est du à une bizarrerie dans l'architecture de certains RISC ISAs et 
n'est pas importante pour nous. Nous gardons juste en téte qu'en MIPS, l'instruction 
qui suit une instruction de saut ou de branchement est exécutée avant l'instruction 
de saut ou de branchement elle-méme. 


Par conséquent, les instructions de branchement échangent toujours leur place avec 
l'instruction qui doit étre exécutée avant. 
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1.4.4 En pratique 


Les fonctions qui retournent simplement 1 (true) ou O (false) sont vraiment fré- 
quentes en pratique. 


Les plus petits utilitaires UNIX standard, /bin/true et /bin/false renvoient respective- 
ment 0 et 1, comme code de retour. (un code retour de zéro signifie en général 
succés, non-zéro une erreur). 


1.5 Hello, world! 


Utilisons le fameux exemple du livre [Brian W. Kernighan, Dennis M. Ritchie, The C 
Programming Language, 2ed, (1988)] : 


#include <stdio.h> 


int main() 

{ 
printf("hello, world\n"); 
return 0; 


1.5.1 x86 
MSVC 
Compilons-le avec MSVC 2010: 


cl l.cpp /Fal.asm 


(L'option /Fa indique au compilateur de générer un fichier avec le listing en assem- 
bleur) 


Listing 1.13 : MSVC 2010 


CONST SEGMENT 

$SG3830 DB ‘hello, world', OAH, 00H 
CONST ENDS 

PUBLIC main 

EXTRN  printf:PROC 

; Function compile flags: /Odtp 

TEXT | SEGMENT 


main PROC 
push ebp 
mov ebp, esp 
push OFFSET $5G3830 
call _printf 
add esp, 4 
xor eax, eax 
pop ebp 
ret 0 


main  ENDP 
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_TEXT ENDS 


MSVC génére des listings assembleur avec la syntaxe Intel. La différence entre la 
syntaxe Intel et la syntaxe AT&T sera discutée dans 1.5.1 on page 15. 


Le compilateur a généré le fichier object 1.0bj, qui sera lié dans l'exécutable 1.exe. 
Dans notre cas, le fichier contient deux segments: CONST (pour les données constantes) 
et TEXT (pour le code). 


La chaine hello, world en C/C++ a le type const char[][Bjarne Stroustrup, The 
C++ Programming Language, 4th Edition, (2013)p176, 7.3.2], mais elle n'a pas de 
nom. Le compilateur doit pouvoir l'utiliser et lui défini donc le nom interne $5G3830 
à cette fin. 


C'est pourquoi l'exemple pourrait étre récrit comme suit: 


#include <stdio.h> 


const char $5G3830[]="hello, world\n"; 


int main() 

{ 
printf ($SG3830) ; 
return 0; 

} 


Retournons au listing assembleur. Comme nous le voyons, la chaîne est terminée 
avec un octet à zéro, ce qui est le standard pour les chaînes C/C++. 


Dans le segment de code, TEXT, il n'y a qu'une seule fonction: main(). La fonc- 
tion main() débute par le code du prologue et se termine par le code de l'épilogue 
(comme presque toutes les fonctions) 1°. 


Aprés le prologue de la fonction nous voyons l'appel à la fonction printf() : 
CALL printf. Avant l'appel, l'adresse de la chaîne (ou un pointeur sur elle) conte- 
nant notre message est placée sur la pile avec l'aide de l'instruction PUSH. 


Lorsque la fonction printf() rend le contróle à la fonction main(), l'adresse de la 
chaíne (ou un pointeur sur elle) est toujours sur la pile. Comme nous n'en avons plus 
besoin, le pointeur de pile (pointeur de pile le registre ESP) doit étre corrigé. 


ADD ESP, 4 signifie ajouter 4 à la valeur du registre ESP. 


Pourquoi 4? puisqu'il s'agit d'un programme 32-bit, nous avons besoin d'exactement 
4 octets pour passer une adresse par la pile. S'il s'agissait d'un code x64, nous au- 
rions besoin de 8 octets. ADD ESP, 4 est effectivement équivalent à POP register 
mais sans utiliser de registre! . 


Pour la méme raison, certains compilateurs (comme le compilateur C++ d'Intel) 
peuvent générer POP ECX à la place de ADD (e.g., ce comportement peut étre obser- 
vé dans le code d'Oracle RDBMS car il est compilé avec le compilateur C++ d'Intel. 


15Vous pouvez en lire plus dans la section concernant les prologues et épilogues de fonctions (1.6 on 
page 41). 
161 es flags du CPU, toutefois, sont modifiés 
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Cette instruction a presque le méme effet mais le contenu du registre ECX sera écra- 
sé. Le compilateur C++ d'Intel utilise probablement POP ECX car l'opcode de cette 
instruction est plus court que celui de ADD ESP, x (1 octet pour POP contre 3 pour 
ADD). 


Voici un exemple d'utilisation de POP à la place de ADD dans Oracle RDBMS : 


Listing 1.14 : Oracle RDBMS 10.2 Linux (app.o file) 


.text:0800029A push ebx 
.text:0800029B call qksfroChild 
.text:080002A0 pop ecx 


Toutefois, MSVC peut faire de méme. 


Listing 1.15 : MineSweeper de Windows 7 32-bit 


.text:0102106F push 0 
.text:01021071 call ds:time 
.text:01021077 pop ecx 


Aprés l'appel de printf(), le code C/C++ original contient la déclaration return 
0 —renvoie 0 comme valeur de retour de la fonction main(). 


Dans le code généré cela est implémenté par l'instruction XOR EAX, EAX. 


XOR est en fait un simple «OU exclusif (eXclusive OR »!7 mais les compilateurs l'uti- 
lisent souvent à la place de MOV EAX, 0—à nouveau parce que l'opcode est légère- 
ment plus court (2 octets pour XOR contre 5 pour MOV). 


Certains compilateurs générent SUB EAX, EAX, qui signifie Soustraire la valeur dans 
EAX de la valeur dans EAX, ce qui, dans tous les cas, donne zéro. 


La derniére instruction RET redonne le contróle à l'appelant. Habituellement, c'est 
ce code C/C++ CRT?$, qui, à son tour, redonne le contrôle à l'OS. 


GCC 


Maintenant compilons le même code C/C++ avec le compilateur GCC 4.4.1 sur Linux: 
gcc 1.c -o 1. Ensuite, avec l'aide du désassembleur IDA, regardons comment la 
fonction main() a été créée. IDA, comme MSVC, utilise la syntaxe Intel??. 


Listing 1.16 : code in IDA 


main proc near 
var 10 - dword ptr -10h 

push ebp 

mov ebp, esp 

and esp, OFFFFFFFOh 
17Wikipédia 


18C Runtime library 
19GCC peut aussi produire un listing assembleur utilisant la syntaxe Intel en lui passant les options -S 
-masm=intel. 
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sub esp, 10h 
mov eax, offset aHelloWorld ; "hello, world\n" 
mov [esp+10h+var_10], eax 
call _printf 
mov eax, 0 
leave 
retn 
main endp 


Le résultat est presque le méme. L'adresse de la chaine hello, world (stockée dans 
le segment de donnée) est d'abord chargée dans le registre EAX puis sauvée sur la 
pile. 

En plus, le prologue de la fonction comprend AND ESP, OFFFFFFFOh —cette instruc- 
tion aligne le registre ESP sur une limite de 16-octet. Ainsi, toutes les valeurs sur la 
pile seront alignées de la méme maniére (Le CPU est plus performant si les adresses 
avec lesquelles il travaille en mémoire sont alignées sur des limites de 4-octet ou 
16-octet). 


SUB ESP, 10h réserve 16 octets sur la pile. Pourtant, comme nous allons le voir, 
seuls 4 sont nécessaires ici. 


C'est parce que la taille de la pile allouée est alignée sur une limite de 16-octet. 


L'adresse de la chaîne est (ou un pointeur vers la chaîne) est stockée directement 
sur la pile sans utiliser l'instruction PUSH. var 10 —est une variable locale et est aussi 
un argument pour printf(). Lisez à ce propos en dessous. 


Ensuite la fonction printf() est appelée. 


Contrairement à MSVC, lorsque GCC compile sans optimisation, il génére MOV EAX, 
0 au lieu d'un opcode plus court. 


La derniére instruction, LEAVE —est équivalente à la paire d'instruction MOV ESP, 
EBP et POP EBP —en d'autres mots, cette instruction déplace le pointeur de pile 
(ESP) et remet le registre EBP dans son état initial. Ceci est nécessaire puisque nous 
avons modifié les valeurs de ces registres (ESP et EBP) au début de la fonction (en 
exécutant MOV EBP, ESP/AND ESP, ..). 


GCC: Syntaxe AT&T 


Voyons comment cela peut-étre représenté en langage d'assemblage avec la syn- 
taxe AT&T. Cette syntaxe est bien plus populaire dans le monde UNIX. 


Listing 1.17 : compilons avec GCC 4.7.3 


gcc -S 1 1.c 


Nous obtenons ceci: 


Listing 1.18 : GCC 4.7.3 


.file "1 l.c" 
.section .rodata 
.LCO: 
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.string "hello, world\n" 


.text 
.globl main 
.type main, @function 
main: 
.LFBO: 
.cfi startproc 
pushl %ebp 
.cfi def cfa offset 8 
.cfi offset 5, -8 
movl “esp, %ebp 
.Cfi def cfa register 5 
andl $-16, %esp 
subl $16, %esp 
movl $.LCO, (%esp) 
call printf 
movl $0, %eax 
leave 
.cfi restore 5 
.cfi def cfa 4, 4 
ret 
.cfi endproc 
.LFEO: 


.Size main, .-main 
.ident "GCC: (Ubuntu/Linaro 4.7.3-lubuntul) 4.7.3" 
section .note.GNU-stack,"",@progbits 


Le listing contient beaucoup de macros (qui commencent avec un point). Cela ne 
nous intéresse pas pour le moment. 


Pour l'instant, dans un souci de simplification, nous pouvons les ignorer (excepté 
la macro .string qui encode une séquence de caractéres terminée par un octet nul, 
comme une chaîne C). Ensuite nous verrons cela?? : 


Listing 1.19 : GCC 4.7.3 


.LC0: 
.string "hello, world\n" 
main: 
pushl %ebp 
movl “esp, %ebp 
andl $-16, %esp 
subl $16, %esp 
movl $.LCO, (%esp) 
call printf 
movl $0, %eax 
leave 
ret 


Quelques-une des différences majeures entre la syntaxe Intel et AT&T sont: 


20Cette option de GCC peut étre utilisée pour éliminer les macros «non nécessaires» : -fno- 
asynchronous-unwind-tables 
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* Opérandes source et destination sont écrites dans l'ordre inverse. 
En syntaxe Intel: «instruction» <opérande de destination «opérande source». 


En syntaxe AT&T: «instruction» «opérande source» <opérande de destina- 
tion». 


Voici un moyen simple de mémoriser la différence: lorsque vous avez affaire 
avec la syntaxe Intel, vous pouvez imaginer qu'il y a un signe égal (=) entre les 
opérandes et lorsque vous avez affaire avec la syntaxe AT&T imaginez qu'il y 
a un flèche droite (>) ?!. 


AT&T: Avant les noms de registres, un signe pourcent doit étre écrit (96) et avant 
les nombres, un signe dollar ($). Les parenthéses sont utilisées à la place des 
crochets. 


* AT&T: un suffixe est ajouté à l'instruction pour définir la taille de l'opérande: 
- q — quad (64 bits) 
- |— long (32 bits) 
- w — word (16 bits) 
- b — byte (8 bits) 


Retournons au résultat compilé: il est identique à ce que l'on voit dans IDA. Avec une 
différence subtile: OFFFFFFFOh est représenté avec $-16. C'est la méme chose: 16 
dans le systéme décimal est 0x10 en hexadécimal. -0x10 est équivalent à OxFFFFFFFO 
(pour un type de donnée sur 32-bit). 


Encore une chose: la valeur de retour est mise à O en utilisant un MOV usuel, pas 
un XOR. MOV charge seulement la valeur dans le registre. Le nom est mal choisi (la 
donnée n'est pas déplacée, mais plutót copiée). Dans d'autres architectures, cette 
instruction est nommée «LOAD » ou «STORE » ou quelque chose de similaire. 


Modification de chaines (Win32) 


Nous pouvons facilement trouver la chaîne "hello, world" dans l'exécutable en utili- 
sant Hiew: 


21À propos, dans certaine fonction C standard (e.g., memcpy(), strcpy()) les arguments sont listés de la 
méme manière que dans la syntaxe Intel: en premier se trouve le pointeur du bloc mémoire de destination, 
et ensuite le pointeur sur le bloc mémoire source. 


Hiew: hw_spanish.exe 


Fig. 1.1: Hiew 


Et nous pouvons essayer de traduire notre message en espagnol: 


Hiew: hw_spanish.exe E 


C:\tmp\hw_spanish.exe  BFWO EDITMODE  PE+ 20000000 0000120D Hiew 8.02 


Fig. 1.2: Hiew 


Le texte en espagnol est un octet plus court que celui en anglais, nous ajoutons 
l'octet OxOA à la fin (Xn) ainsi qu'un octet à zéro. 


Ca fonctionne. 

Comment faire si nous voulons insérer un message plus long ? Il y a quelques octets à 
zéro aprés le texte original en anglais. Il est difficile de dire s'ils peuvent étre écrasés: 
ils peuvent étre utilisés quelque part dans du code CRT, ou pas. De toutes facons, 
écrasez-les seulement si vous savez vraiment ce que vous faites. 

Modification de chaines (Linux x64) 

Essayons de modifier un exécutable Linux x64 en utilisant rada.re : 


Listing 1.20 : rada.re session 


dennis@bigbox ~/tmp % gcc hw.c 


dennis@bigbox ~/tmp % radare2 a.out 

-- SHALL WE PLAY A GAME? 

[0x00400430]> / hello 

Searching 5 bytes from 0x00400000 to 0x00601040: 68 65 6c 6c 6f 
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Searching 5 bytes in [0x400000-0x601040] 
hits: 1 
0x004005c4 hit0_0 .HHhello, world;0. 


[0x00400430]> s 0x004005c4 


[0x004005c4]» px 

- offset - 0123 45 67 89 AB CD EF 0123456789ABCDEF 
0x004005c4 6865 6c6c 6f2c 2077 6f72 6c64 0000 0000 hello, world.... 
0x004005d4 011b 033b 3000 0000 0500 0000 1cfe ffff ...;0........... 
0x004005e4 7c00 0000 5cfe ffff 4c00 0000 52ff ffff |...\...L...R... 
0x004005f4 a400 0000 6cff ffff c400 0000 dcff ffff  ....1........... 
0x00400604 Oc01 0000 1400 0000 0000 0000 017a 5200 ............. zR. 
0x00400614 0178 1001 1b0c 0708 9001 0710 1400 0000 .x.............. 
0x00400624 1c00 0000 08fe ffff 2a00 0000 0000 0000 ........ GERE ns 
0x00400634 0000 0000 1400 0000 0000 0000 017a 5200 ............. zR. 
0x00400644 0178 1001 1b0c 0708 9001 0000 2400 0000 .x.......... $... 
0x00400654 1c00 0000 98fd ffff 3000 0000 000e 1046 ........ Dri F 
0x00400664 0el8 4a0f 0b77 0880 003f 1a3b 2a33 2422 ..J..w...?.;*3$" 
0x00400674 0000 0000 1c00 0000 4400 0000 a6fe ffff ........ Dies eee 
0x00400684 1500 0000 0041 0e10 8602 430d 0650 0c07 ..... Arias CP 
0x00400694 0800 0000 4400 0000 6400 0000 a0fe ffff ....D...d....... 
0x004006a4 6500 0000 0042 0e10 8f02 420e 188e 0345 e....B....B....E 
0x004006b4 0e20 8d04 420e 288c 0548 0e30 8606 480e . ..B.(..H.0..H. 


[0x004005c4]> oo+ 
File a.out reopened in read-write mode 


[0x004005c4]> w hola, mundo\x00 
[0x004005c4]> q 


dennis@bigbox -/tmp % ./a.out 
hola, mundo 


Ce que je fais ici: je cherche la chaine «hello » en utilisant la commande /, ensuite je 
déplace le curseur (ou seek selon la terminologie de rada.re) à cette adresse. Je veux 
être certain d’être à la bonne adresse: px affiche les octets ici. oo passe rada.re en 
mode read-write. w écrit une chaîne ASCII à la seek (position) courante. Notez le 100 
à la fin-c'est l'octet à zéro. q quitte. 


subsubsectionCeci est une histoire vraie de modification de logiciel 


Un logiciel de traitement d'image, lorsqu'il n'était pas enregistré, ajoutait un ta- 
touage numérique comme "Cette image a été traitée par la version d'évaluation 
de [nom du logiciel]", à travers l'image. Nous avons essayé au hasard: nous avons 
trouvé cette chaíne dans le fichier exécutable et avons mis des espaces à la place. 
Le tatouage a disparu. Techniquement parlant, il continuait d'apparaitre. Avec l'aide 
des fonctions Qt, le tatouage numérique était toujours ajouté à l'image résultante. 
Mais ajouter des espaces n'altérait pas l'image elle-méme... 
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Traduction de logiciel à l'ére MS-DOS 


La méthode que je viens de décrire était couramment employée pour traduire des 
logiciels sous MS-DOS en russe dans les années 1980 et 1990. Cette technique est 
accessible méme pour ceux qui ne connaissent pas le code machine et les formats 
de fichier exécutable. La nouvelle chaîne ne doit être pas être plus longue que l'an- 
cienne, car il y a un risque d'écraser une autre valeur ou du code ici. Les mots et 
les phrases russes sont en général un peu plus longs qu'en anglais, c'est pourquoi 
les logiciels traduits sont pleins d'acronymes sibyllins et d'abréviations difficilement 
lisibles. 


Fig. 1.3: Norton Commander 5.51 localisé 


Peut-étre que cela s'est produit pour d'autres langages durant cette période. 


En ce qui concerne Delphi, la taille de la chaîne de caractères doit elle aussi être 
ajustée. 
1.5.2 x86-64 
MSVC: x86-64 
Essayons MSVC 64-bit: 
Listing 1.21 : MSVC 2012 x64 


$5G2989 DB 'hello, world', 0AH, 00H 
main PROC 
sub rsp, 40 
lea rcx, OFFSET FLAT:$5G2989 
call printf 
xor eax, eax 
add rsp, 40 
ret 0 
main ENDP 


En x86-64, tous les registres ont été étendus à 64-bit et leurs noms ont maintenant 
le préfixe R-. Afin d'utiliser la pile moins souvent (en d'autres termes, pour accéder 
moins souvent à la mémoire externe/au cache), il existe un moyen répandu de passer 
les arguments aux fonctions par les registres (fastcall) 6.1.3 on page 955. l.e., une 
partie des arguments de la fonction est passée par les registres, le reste—par la pile. 
En Win64, 4 arguments de fonction sont passés dans les registres RCX, RDX, R8, R9. 
C'est ce que l'on voit ci-dessus: un pointeur sur la chaine pour printf() est passé 
non pas par la pile, mais par le registre RCX. Les pointeurs font maintenant 64-bit, ils 
sont donc passés dans les registres 64-bit (qui ont le préfixe R-). Toutefois, pour la 
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rétrocompatibilité, il est toujours possible d'accéder à la partie 32-bits des registres, 
en utilisant le préfixe E-. Voici à quoi ressemblent les registres RAX/EAX/AX/AL en 
x86-64: 


Octet d’indice 
716 5413/1211 0 
RAX* 


AH | AL 


La fonction main () renvoie un type int, qui est, en C/C++, pour une meilleure rétro- 
compatibilité et portabilité, toujours 32-bit, c'est pourquoi le registre EAX est mis à 
zéro à la fin de la fonction (i.e., la partie 32-bit du registre) au lieu de RAX. Il y aussi 
40 octets alloués sur la pile locale. Cela est appelé le «shadow space », dont nous 
parlerons plus tard: 1.14.2 on page 137. 


GCC: x86-64 
Essayons GCC sur un Linux 64-bit: 
Listing 1.22 : GCC 4.4.6 x64 


.string "hello, world\n" 


main: 
sub rsp, 8 
mov edi, OFFSET FLAT:.LCO ; "hello, world^n" 
xor eax, eax ; nombre de registres vectoriels 
call printf 
xor eax, eax 
add rsp, 8 
ret 


Une méthode de passage des arguments à la fonction dans des registres est aussi 
utilisée sur Linux, *BSD et Mac OS X est [Michael Matz, Jan Hubicka, Andreas Jaeger, 
Mark Mitchell, System V Application Binary Interface. AMD64 Architecture Processor 
Supplement, (2013)] ?. Linux, *BSD et Mac OS X utilisent aussi une méthode pour 
passer les arguments d'une fonction par les registres: [Michael Matz, Jan Hubicka, 
Andreas Jaeger, Mark Mitchell, System V Application Binary Interface. AMD64 Archi- 
tecture Processor Supplement, (2013)] ??. 


Les 6 premiers arguments sont passés dans les registres RDI, RSI, RDX, RCX, R8, R9 
et les autres— par la pile. 


Donc le pointeur sur la chaíne est passé dans EDI (la partie 32-bit du registre). Mais 
pourquoi ne pas utiliser la partie 64-bit, RDI? 


Il est important de garder à l'esprit que toutes les instructions MOV en mode 64-bit qui 
écrivent quelque chose dans la partie 32-bit inférieuaer du registre efface également 


22Aussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64-abi.pdf 

23Aussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64-abi.pdf 
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les 32-bit supérieurs (comme indiqué dans les manuels Intel: 12.1.4 on page 1315). 
l.e., l'instruction MOV EAX, 011223344h écrit correctement une valeur dans RAX, puisque 
que les bits supérieurs sont mis à zéro. 


Si nous ouvrons le fichier objet compilé (.0), nous pouvons voir tous les opcodes des 
instructions ?^ : 


Listing 1.23 : GCC 4.4.6 x64 


.text:00000000004004D0 main proc near 

.text:00000000004004D0 48 83 EC 08 sub rsp, 8 

.text:00000000004004D4 BF E8 05 40 00 mov edi, offset format ; "hello, 
world n" 

text. 0000000000400409 31 CO xor eax, eax 

.text:00000000004004DB E8 D8 FE FF FF call | printf 

.text:00000000004004E0 31 CO xor eax, eax 

.text:00000000004004E2 48 83 C4 08 add rsp, 8 

.text:00000000004004E6 C3 retn 

.text:00000000004004E6 main endp 


Comme on le voit, l'instruction qui écrit dans EDI en 0x4004D4 occupe 5 octets. La 
méme instruction qui écrit une valeur sur 64-bit dans RDI occupe 7 octets. I| semble 
que GCC essaye d'économiser un peu d'espace. En outre, cela permet d'étre sür 
que le segment de données contenant la chaine ne sera pas alloué à une adresse 
supérieure à 4 GiB. 


Nous voyons aussi que le registre EAX est mis à zéro avant l'appel à la fonction 
printf().Ceci, car conformément à l'ABI? standard mentionnée plus haut, le nombre 
de registres vectoriel utilisés est passé dans EAX sur les systémes *NIX en x86-64. 


Modification d'adresse (Win64) 


Lorsque notre exemple est compilé sous MSVC 2013 avec l'option /MD (générant un 
exécutable plus petit du fait du lien avec MSVCR* .DLL), la fonction main() vient en 
premier et est trouvée facilement: 


24Ceci doit être activé dans Options ^ Disassembly > Number of opcode bytes 
25 Application Binary Interface 
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rcx 


Fig. 1.4: Hiew 


A titre expérimental, nous pouvons incrémenter l'adresse du pointeur de 1: 


Hiew: hw2.exe 


‘ello, v 


Fig. 1.5: Hiew 


Hiew montre la chaíne «ello, world ». Et lorsque nous lancons l'exécutable modifié, 
la chaine raccourcie est affichée. 


Utiliser une autre chaine d'un binaire (Linux x64) 


Le fichier binaire que j'obtiens en compilant notre exemple avec GCC 5.4.0 sur un 
systéme Linux x64 contient de nombreuses autres chaines: la plupart sont des noms 
de fonction et de bibliothéque importées. 


Je lance objdump pour voir le contenu de toutes les sections du fichier compilé: 


$ objdump -s a.out 
a.out: file format elf64-x86-64 


Contents of section .interp: 

400238 2f6c6962 36342f6c 642d6c69 6e75782d /lib64/ld-linux- 
400248 7838362d 36342e73 6f2e3200 x86-64.50.2. 
Contents of section .note.ABI-tag: 

400254 04000000 10000000 01000000 47465500 ............ GNU. 
400264 00000000 02000000 06000000 20000000 ............ T 
Contents of section .note.gnu.build-id: 
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400274 04000000 14000000 03000000 474e5500 ............ GNU. 
400284 fe461178 5bb710b4 bbf2aca8 5eclec10 .F.x[....... sd 
400294 cf3f7ae4 .?Z. 


Ce n'est pas un probléme de passer l'adresse de la chaîne «/lib64/ld-linux-x86-64.s0.2 » 
à l'appel de printf() : 


#include <stdio.h> 


int main() 

{ 
printf (0x400238) ; 
return 0; 


} 


Difficile a croire, ce code affiche la chaine mentionnée. 


Changez l'adresse en 0x400260, et la chaíne «GNU» sera affichée. L’adresse est 
valable pour cette version spécifique de GCC, outils GNU, etc. Sur votre systéme, 
l'exécutable peut étre légérement différent, et toutes les adresses seront différentes. 
Ainsi, ajouter/supprimer du code à/de ce code source va probablement décaler les 
adresses en arriére et avant. 


1.5.3 ARM 


Pour mes expérimentations avec les processeurs ARM, différents compilateurs ont 
été utilisés: 

* Trés courant dans le monde de l'embarqué: Keil Release 6/2013. 

* Apple Xcode 4.6.3 IDE avec le compilateur LLVM-GCC 4.2 ?9 


* GCC 4.9 (Linaro) (pour ARM64), disponible comme exécutable win32 ici http: 
//www.linaro.org/projects/armve/. 


C'est du code ARM 32-bit qui est utilisé (également pour les modes Thumb et Thumb- 
2) dans tous les cas dans ce livre, sauf mention contraire. 


sans optimisation Keil 6/2013 (Mode ARM) 


Commencons par compiler notre exemple avec Keil: 


armcc.exe --arm --c90 -00 1.c 


Le compilateur armcc produit un listing assembleur en syntaxe Intel, mais il dispose 
de macros de haut niveau liées au processeur ARM?”. Comme il est plus important 


26C'est ainsi: Apple Xcode 4.6.3 utilise les composants open-source GCC comme front-end et LIVM 
comme générateur de code 
27e.g. les instructions PUSH/POP manquent en mode ARM 
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pour nous de voir les instructions «telles quelles », nous regardons le résultat compilé 
dans IDA. 


Listing 1.24 : sans optimisation Keil 6/2013 (Mode ARM) IDA 


.text:00000000 main 

.text:00000000 10 40 2D E9 STMFD SP!, {R4,LR} 

.text:00000004 1E OE 8F E2 ADR RO, aHelloWorld ; "hello, world" 

.text:00000008 15 19 00 EB BL __2printf 

.text:0000000C 00 00 AO E3 MOV RO, 40 

.text:00000010 10 80 BD E8 LDMFD SP!, {R4,PC} 

.text:000001EC 68 65 6C 6C+aHelloWorld DCB "hello, world",0 ; DATA XREF: 
main+4 


Dans l'exemple, nous voyons facilement que chaque instruction a une taille de 4 
octets. En effet, nous avons compilé notre code en mode ARM, pas pour Thumb. 


La toute première instruction, STMFD SP!, {R4,LR}2°, fonctionne comme une ins- 
truction PUSH en x86, écrivant la valeur de deux registres (R4 et LR) sur la pile. 


En effet, dans le listing de la sortie du compilateur armcc, dans un souci de simplifica- 
tion, il montre l'instruction PUSH {r4,1r}. Mais ce n'est pas trés précis. L'instruction 
PUSH est seulement disponible dans le mode Thumb. Donc, pour rendre les choses 
moins confuses, nous faisons cela dans IDA. 


Cette instruction décrémente d'abord le pointeur de pile SP?? pour qu'il pointe sur de 
l'espace libre pour de nouvelles entrées, ensuite elle sauve les valeurs des registres 
R4 et LR à cette adresse. 


Cette instruction (comme l'instruction PUSH en mode Thumb) est capable de sauve- 
garder plusieurs valeurs de registre à la fois, ce qui peut étre trés utile. À propos, elle 
n'a pas d'équivalent en x86. On peut noter que l'instruction STMFD est une générali- 
sation de l'instruction PUSH (étendant ses fonctionnalités), puisqu'elle peut travailler 
avec n'importe quel registre, pas seulement avec SP. En d'autres mots, l'instruction 
STMFD peut étre utilisée pour stocker un ensemble de registres à une adresse don- 
née. 


L'instruction ADR RO, aHelloWorld ajoute ou soustrait la valeur dans le registre 
PC?! à l'offset où la chaîne hello, world se trouve. On peut se demander comment 
le registre PC est utilisé ici? C'est appelé du «code indépendant de la position »??. 


Un tel code peut étre exécuté à n'importe quelle adresse en mémoire. En d'autres 
mots, c'est un adressage PC-relatif. L'instruction ADR prend en compte la différence 
entre l'adresse de cette instruction et l'adresse où est située la chaîne. Cette diffé- 
rence (offset) est toujours la méme, peu importe à quelle adresse notre code est char- 
gé par l'OS. C'est pourquoi tout ce dont nous avons besoin est d'ajouter l'adresse de 
l'instruction courante (du PC) pour obtenir l'adresse absolue en mémoire de notre 
chaine C. 


28STMFD?9 

30pointeur de pile. SP/ESP/RSP dans x86/x64. SP dans ARM. 
31Program Counter. IP/EIP/RIP dans x86/64. PC dans ARM. 
321 ire à ce propos la section(6.4.1 on page 974) 
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L'instruction BL  2printf** appelle la fonction printf (). Voici comment fonctionne 
cette instruction: 


* sauve l'adresse suivant l'instruction BL (0xC) dans LR; 
* puis passe le contróle à printf() en écrivant son adresse dans le registre PC. 


Lorsque la fonction printf() termine son exécution elle doit avoir savoir oü elle doit 
redonner le contróle. C'est pourquoi chaque fonction passe le contróle à l'adresse 
se trouvant dans le registre LR. 


C'est une différence entre un processeur RISC «pur» comme ARM et un processeur 
CISC?^ comme x86, oü l'adresse de retour est en général sauvée sur la pile. Pour 
aller plus loin, lire la section (1.9 on page 42) suivante. 


À propos, une adresse absolue ou un offset de 32-bit ne peuvent étre encodés dans 
l'instruction 32-bit BL car il n'y a qu'un espace de 24 bits. Comme nous devons 
nous en souvenir, toutes les instructions ont une taille de 4 octets (32 bits). Par 
conséquent, elles ne peuvent se trouver qu'à des adresses alignées dur des limites 
de 4 octets. Cela implique que les 2 derniers bits de l'adresse d'une instruction (qui 
sont toujours des bits à zéro) peuvent étre omis. En résumé, nous avons 26 bits pour 
encoder l'offset. C'est assez pour encoder current PC + » 32M. 


Ensuite, l'instruction MOV RO, #0% écrit juste O dans le registre RO. C'est parce que 
notre fonction C renvoie 0 et la valeur de retour doit étre mise dans le registre RO. 


La dernière instruction est LDMFD SP!, R4,PC*6. Elle prend des valeurs sur la pile (ou 
de toute autre endroit en mémoire) afin de les sauver dans R4 et PC, et incrémente 
le pointeur de pile SP. Cela fonctionne ici comme POP. 

N.B. La toute premiére instruction STMFD a sauvé la paire de registres R4 et LR sur 
la pile, mais R4 et PC sont restaurés pendant l'exécution de LDMFD. 


Comme nous le savons déjà, l'adresse oü chaque fonction doit redonner le contróle 
est usuellement sauvée dans le registre LR. La toute premiére instruction sauve sa 
valeur sur la pile car le méme registre va étre utilisé par notre fonction main() lors 
de l'appel à printf(). A la fin de la fonction, cette valeur peut étre écrite directe- 
ment dans le registre PC, passant ainsi le contróle là oü notre fonction a été appelée. 
Comme main() est en général la premiére fonction en C/C++, le contróle sera re- 
donné au chargeur de l'OS ou a un point dans un CRT, ou quelque chose comme 
ca. 


Tout cela permet d'omettre l'instruction BX LR à la fin de la fonction. 


DCB est une directive du langage d'assemblage définissant un tableau d'octets ou 
des chaínes ASCII, proche de la directive DB dans le langage d'assemblage x86. 


sans optimisation Keil 6/2013 (Mode Thumb) 


Compilons le méme exemple en utilisant keil en mode Thumb: 


33Branch with Link 

3^Complex Instruction Set Computing 
35Signifiant MOVe 

36LDMFD”” est l'instruction inverse de STMFD 
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armcc.exe --thumb --c90 -00 1.c 


Nous obtenons (dans IDA) : 
Listing 1.25 : sans optimisation Keil 6/2013 (Mode Thumb) + IDA 


.text:00000000 main 

.text:00000000 10 B5 PUSH (RA,LR) 

.text:00000002 CO AO ADR RO, aHelloWorld ; "hello, world" 

.text:00000004 06 FO 2E F9 BL __2printf 

.text:00000008 00 20 MOVS RO, #0 

.text:0000000A 10 BD POP {R4,PC} 

.text:00000304 68 65 6C 6C+aHelloWorld DCB "hello, world",0 ; DATA XREF: 
main+2 


Nous pouvons repérer facilement les opcodes sur 2 octets (16-bit). C'est, comme 
déja noté, Thumb. L'instruction BL, toutefois, consiste en deux instructions 16-bit. 
C'est parce qu'il est impossible de charger un offset pour la fonction printf() en 
utilisant seulement le petit espace dans un opcode 16-bit. Donc, la première instruc- 
tion 16-bit charge les 10 bits supérieurs de l'offset et la seconde instruction les 11 
bits inférieurs de l'offset. 


Comme il a été écrit, toutes les instructions en mode Thumb ont une taille de 2 
Octets (ou 16 bits). Cela implique qu'il impossible pour une instruction Thumb d'étre 
à une adresse impaire, quelle qu'elle soit. En tenant compte de cela, le dernier bit 
de l'adresse peut étre omis lors de l'encodage des instructions. 


En résumé, l'instruction Thumb BL peut encoder une adresse en current PC + «2M. 


Comme pour les autres instructions dans la fonction: PUSH et POP fonctionnent ici 
comme les instructions décrites STMFD/LDMFD seul le registre SP n'est pas mentionné 
explicitement ici. ADR fonctionne comme dans l'exemple précédent. MOVS écrit O dans 
le registre RO afin de renvoyer zéro. 


avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Xcode 4.6.3 sans l'option d'optimisation produit beaucoup de code redondant c'est 
pourquoi nous allons étudier le code généré avec optimisation, oü le nombre d'ins- 
truction est aussi petit que possible, en mettant l'option -03 du compilateur. 


Listing 1.26 : avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


__text :000028C4 _hello world 

. text:000028C4 80 40 2D E9 STMFD SP!, {R7,LR} 
. text:000028C8 86 06 01 E3 MOV RO, #0x1686 
. text:000028CC OD 70 AQ El MOV R7, SP 

. text:000028D0 00 00 40 E3  MOVT RO, 40 

. text:000028D4 00 00 8F EO ADD RO, PC, RO 

. text:000028D8 C3 05 00 EB BL | puts 

. text:000028DC 00 00 AO E3 MOV RO, 40 
__text:000028E0 80 80 BD E8  LDMFD SP!, {R7,PC} 


. Cstring:00003F62 48 65 6C 6C+aHelloWorld 0 DCB "Hello world!",0 
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Les instructions STMFD et LDMFD nous sont déjà familiéres. 


L'instruction MOV écrit simplement le nombre 0x1686 dans le registre RO. C'est l'offset 
pointant sur la chaîne «Hello world! ». 


Le registre R7 (tel qu'il est standardisé dans [iOS ABI Function Call Guide, (2010)]?9) 
est un pointeur de frame. Voir plus loin. 


L'instruction MOVT RO, 40 (MOVe Top) écrit O dans les 16 bits de poids fort du registre. 
Le probléme ici est que l'instruction générique MOV en mode ARM peut n'écrire que 
dans les 16 bits de poids faible du registre. 


Il faut garder à l'esprit que tout les opcodes d'instruction en mode ARM sont limités 
en taille à 32 bits. Bien sûr, cette limitation n'est pas relative au déplacement de 
données entre registres. C'est pourquoi une instruction supplémentaire existe MOVT 
pour écrire dans les bits de la partie haute (de 16 à 31 inclus). Son usage ici, toutefois, 
est redondant car l'instruction MOV RO, #0x1686 ci dessus a effacé la partie haute 
du registre. C'est soi-disant un défaut du compilateur. 


L'instruction ADD RO, PC, RO ajoute la valeur dans PC à celle de RO, pour calculer 
l'adresse absolue de la chaine «Hello world! ». Comme nous l'avons déjà vu, il s'agit 
de «code indépendant de la position » donc la correction est essentielle ici. 


L'instruction BL appelle la fonction puts() au lieu de printf(). 


LLVM a remplacé le premier appel à printf() paruna puts(). Effectivement: printf() 
avec un unique argument est presque analogue à puts(). 


Presque, car les deux fonctions produisent le méme résultat uniquement dans le cas 
oü la chaine ne contient pas d'identifiants de format débutant par %. Dans le cas oü 
elle en contient, l'effet de ces deux fonctions est différent??. 


Pourquoi est-ce que le compilateur a remplacé printf() par puts() ? Probablement 
car puts() est plus rapide^?. 


Car il envoie seulement les caractéres dans sortie standard sans comparer chacun 
d'entre eux avec le symbole 96. 


Ensuite, nous voyons l'instruction familiére MOV RO, #0 pour mettre le registre RO à 
0. 

avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 

Par défaut Xcode 4.6.3 génére du code pour Thumb-2 de cette maniére: 


Listing 1.27 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


. text:00002B6C hello world 

_ text:00002B6C 80 B5 PUSH {R7,LR} 

. text:00002B6E 41 F2 D8 30 MOVW RO, #0x13D8 
. text:00002B72 6F 46 MOV R7, SP 


38Aussi disponible en http://developer.apple.com/library/ios/documentation/Xcode/ 
Conceptual/iPhoneOSABIReference/iPhoneOSABIReference.pdf 

39|| est à noter que puts() ne nécessite pas un ^n' symbole de retour à la ligne à la fin de la chaîne, 
donc nous ne le voyons pas ici. 

^0ciselant.de/projects/gcc printf/gcc printf.html 
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. text:00002B74 CO F2 00 00 MOVT.W RO, #0 
. text:00002B78 78 44 ADD RO, PC 
. text:00002B7A 01 FO 38 EA BLX puts 

. text:00002B7E 00 20 MOVS RO, #0 
. text:00002B80 80 BD POP {R7,PC} 


. Cstring:00003E70 48 65 6C 6C 6F 20+aHelloWorld DCB "Hello world!",0xA,0 


Les instructions BL et BLX en mode Thumb, comme on s'en souvient, sont encodées 
comme une paire d'instructions 16 bits. En Thumb-2 ces opcodes substituts sont 
étendus de telle sorte que les nouvelles instructions puissent étre encodées comme 
des instructions 32-bit. 


C'est évident en considérant que les opcodes des instructions Thumb-2 commencent 
toujours avec OxFx ou OxEx. 


Mais dans le listing d'IDA les octets d'opcodes sont échangés car pour le processeur 
ARM les instructions sont encodées comme ceci: dernier octet en premier et ensuite 
le premier (pour les modes Thumb et Thumb-2) ou pour les instructions en mode 
ARM le quatrieme octet vient en premier, ensuite le troisiéme, puis le second et 
enfin le premier (à cause des différents endianness). 


C'est ainsi que les octets se trouvent dans le listing d'IDA: 
* pour les modes ARM et ARM64: 4-3-2-1; 
* pour le mode Thumb: 2-1; 
* pour les paires d'instructions 16-bit en mode Thumb-2: 2-1-4-3. 


Donc, comme on peut le voir, les instructions MOVW, MOVT.W et BLX commencent par 
OxFx. 


Une des instructions Thumb-2 est MOVW RO, #0x13D8 —elle stocke une valeur 16-bit 
dans la partie inférieure du registre RO, effacant les bits supérieurs. 


Aussi, MOVT.W RO, £0 fonctionne comme MOVT de l'exemple précédent mais il fonc- 
tionne en Thumb-2. 


Parmi les autres différences, l'instruction BLX est utilisée dans ce cas à à la place de 
BL. 


La différence est que, en plus de sauver RA^! dans le registre LR et de passer le 
contróle à la fonction puts(), le processeur change du mode Thumb/Thumb-2 au 
mode ARM (ou inversement). 


Cette instruction est placée ici, car l'instruction à laquelle est passée le contróle 
ressemble à (c'est encodé en mode ARM) : 


. Symbolstub1:00003FEC puts ; CODE XREF: hello world+E 
. Symbolstub1:00003FEC 44 FO 9F E5 LDR PC, = imp puts 


41Adresse de retour 
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Il s'agit principalement d'un saut à l'endroit où l'adresse de puts() est écrit dans la 
section import. 


Mais alors, le lecteur attentif pourrait demander: pourquoi ne pas appeler puts() 
depuis l'endroit dans le code oü on en a besoin? 


Parce que ce n'est pas trés efficace en terme d'espace. 


Presque tous les programmes utilisent des bibliothéques dynamiques externes (comme 
les DLL sous Windows, les .so sous *NIX ou les .dylib sous Mac OS X). Les biblio- 
théques dynamiques contiennent les bibliothéques fréquemment utilisées, incluant 
la fonction C standard puts(). 


Dans un fichier binaire exécutable (Windows PE .exe, ELF ou Mach-O) se trouve une 
section d'import. Il s'agit d'une liste des symboles (fonctions ou variables globales) 
importées depuis des modules externes avec le nom des modules eux-méme. 


Le chargeur de l'OS charge tous les modules dont il a besoin, tout en énumérant 
les symboles d'import dans le module primaire, il détermine l'adresse correcte de 
chaque symbole. 


Dans notre cas, imp puts est une variable 32-bit utilisée par le chargeur de l'OS 
pour sauver l'adresse correcte d'une fonction dans une bibliothéque externe. Ensuite 
l'instruction LDR lit la valeur 32-bit depuis cette variable et l'écrit dans le registre PC, 
lui passant le contróle. 


Donc, pour réduire le temps dont le chargeur de l'OS à besoin pour réaliser cette 
procédure, c'est une bonne idée d'écrire l'adresse de chaque symbole une seule 
fois, à une place dédiée. 


À cóté de ca, comme nous l'avons déjà compris, il est impossible de charger une 
valeur 32-bit dans un registre en utilisant seulement une instruction sans un accés 
mémoire. 


Donc, la solution optimale est d'allouer une fonction séparée fonctionnant en mode 
ARM avec le seul but de passer le contróle à la bibliothéque dynamique et ensuite de 
sauter à cette petite fonction d'une instruction (ainsi appelée fonction thunk) depuis 
le code Thumb. 


À propos, dans l'exemple précédent (compilé en mode ARM), le contróle est pas- 
sé par BL à la méme fonction thunk. Le mode du processeur, toutefois, n'est pas 
échangé (d'où l'absence d'un «X» dans le mnémonique de l'instruction). 


Plus à propos des fonctions thunk 


Les fonctions thunk sont difficile à comprendre, apparemment, à cause d'un mau- 
vais nom. La maniére la plus simple est de les voir comme des adaptateurs ou des 
convertisseurs d'un type jack à un autre. Par exemple, un adaptateur permettant 
l'insertion d'un cordon électrique britannique sur une prise murale américaine, ou 
vice-versa. Les fonctions thunk sont parfois appelées wrappers. 


Voici quelques autres descriptions de ces fonctions: 
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“Un morceau de code qui fournit une adresse:", d'aprés P. Z. In- 
german, qui inventa thunk en 1961 comme un moyen de lier les para- 
mètres réels à leur définition formelle dans les appels de procédures en 
Algol-60. Si une procédure est appelée avec une expression à la place 
d'un paramétre formel, le compilateur génére un thunk qui calcule l'ex- 
pression et laisse l'adresse du résultat dans une place standard. 


Microsoft et IBM ont tous les deux défini, dans systémes basés sur 
Intel, un "environnement 16-bit" (avec leurs horribles registres de seg- 
ment et la limite des adresses à 64K) et un "environnement 32-bit" 
(avec un adressage linéaire et une gestion semi-réelle de la mémoire). 
Les deux environnements peuvent fonctionner sur le méme ordinateur 
et OS (gráce à ce qui est appelé, dans le monde Microsoft, WOW qui 
signifie Windows dans Windows). MS et IBM ont tous deux décidé que 
le procédé de passer de 16-bit à 32-bit et vice-versa est appelé un 
"thunk"; pour Window 95, il y a méme un outil, THUNK.EXE, appelé un 
"compilateur thunk". 


( The Jargon File ) 


Nous pouvons trouver un autre exemple dans la bibliothéque LAPCAK—un "Linear 
Algebra PACKage" écrit en FORTRAN. Les développeurs C/C++ veulent aussi utiliser 
LAPACK, mais c'est un non-sens de la récrire en C/C++ et de maintenir plusieurs 
versions. Donc, il y a des petites fonctions que l'on peut invoquer depuis un environ- 
nement C/C++, qui font, à leur tour, des appels aux fonctions FORTRAN, et qui font 
presque tout le reste: 


double Blas Dot Prod(const LaVectorDouble &dx, const LaVectorDouble &dy) 
{ 
assert(dx.size()==dy.size()); 
integer n = dx.size(); 
integer incx = dx.inc(), incy = dy.inc(); 


return F77NAME(ddot)(&n, &dx(0), &incx, &dy(0), &incy); 
} 


Donc, ce genre de fonctions est appelé “wrappers”. 


ARM64 
GCC 


Compilons l'exemple en utilisant GCC 4.8.1 en ARM64: 
Listing 1.28 : GCC 4.8.1 sans optimisation + objdump 


1 |0000000000400590 «main»: 
2 | 400590: a9bf7bfd stp x29, x30, [sp,#-16]! 
3 | 400594: 910003fd mov x29, sp 


PERRA 
BüUuNHOY10-ou n 


33 


400598: 90000000 adrp x0, 400000 < init-0x3b8» 
40059c: 91192000 add x0, x0, #0x648 

4005a0: 97ffffa0 bl 400420 <puts@plt> 
400524: 52800000 mov wO, #0x0 // #0 

4005a8: a8c17bfd ldp x29, x30, [sp],#16 
4005ac: d65f03c0 ret 


Contents of section .rodata: 
400640 01000200 00000000 48656c6c 6f210a00 ........ Hello!.. 


Il n'y a pas de mode Thumb ou Thumb-2 en ARM64, seulement en ARM, donc il n'y 
a que des instructions 32-bit. Le nombre de registres a doublé: .2.4 on page 1351. 
Les registres 64-bit ont le préfixe X-, tandis que leurs partie 32-bit basse—W-. 


L'instruction STP (Store Pair stocke une paire) sauve deux registres sur la pile simul- 
tanément: X29 et X30. 


Bien sür, cette instruction peut sauvegarder cette paire à n'importe quelle endroit 
en mémoire, mais le registre SP est spécifié ici, donc la paire est sauvé sur le pile. 


Les registres ARM64 font 64-bit, chacun a unetaille de 8 octets, donc il faut 16 octets 
pour sauver deux registres. 


Le point d'exclamation ("!") aprés l'opérande signifie que 16 octets doivent d'abord 
étre soustrait de SP, et ensuite les valeurs de la paire de registres peuvent étre 
écrites sur la pile. Ceci est appelé le pre-index. À propos de la différence entre post- 
index et pre-index lisez ceci: 1.39.2 on page 568. 


Dans la gamme plus connue du x86, la premiére instruction est analogue à la paire 
PUSH X29 et PUSH X30. En ARM64, X29 est utilisé comme FP et X30 comme LR, 
c'est pourquoi ils sont sauvegardés dans le prologue de la fonction et remis dans 
l'épilogue. 


La seconde instruction copie SP dans X29 (ou FP). Cela sert à préparer la pile de la 
fonction. 


Les instructions ADRP et ADD sont utilisées pour remplir l'adresse de la chaíne «Hel- 
lo! » dans le registre X0, car le premier argument de la fonction est passé dans ce 
registre. Il n'y a pas d'instruction, quelqu'elle soit, en ARM qui puisse stocker un 
nombre large dans un registre (car la longueur des instructions est limitée à 4 oc- 
tets, cf: 1.39.3 on page 570). Plusieurs instructions doivent donc étre utilisées. La 
première instruction (ADRP) écrit l'adresse de la page de 4KiB, où se trouve la chaîne, 
dans X6, et la seconde (ADD) ajoute simplement le reste de l'adresse. Plus d'informa- 
tion ici: 1.39.4 on page 572. 


0x400000 + 0x648 = 0x400648, et nous voyons notre chaine C «Hello! » dans le 
. rodata segment des données à cette adresse. 


puts() est appelée aprés en utilisant l'instruction BL. Cela a déjà été discuté: 1.5.3 
on page 29. 


^?Frame Pointer 
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MOV écrit O dans WO. WO est la partie basse 32 bits du registre 64-bit XO : 


Partie 32 bits haute | Partie 32 bits basse 
XO 


WO 


Le résultat de la fonction est retourné via X0 et main renvoie 0, donc c'est ainsi que 
la valeur de retour est préparée. Mais pourquoi utiliser la partie 32-bit? 


Parce que le type de donnée int en ARM64, tout comme en x86-64, est toujours 
32-bit, pour une meilleure compatibilité. 


Donc si la fonction renvoie un int 32-bit, seul les 32 premiers bits du registre X0 
doivent étre remplis. 


Pour vérifier ceci, changeons un peu cet exemple et recompilons-le. Maintenant, 
main() renvoie une valeur sur 64-bit: 


Listing 1.29 : main() renvoie une valeur de type uint64 t type 


#include <stdio.h> 
#include <stdint.h> 


uint64 t main() 

1 
printf ("Hello!\n"); 
return 0; 


} 


Le résultat est le méme, mais c’est a quoi ressemble MOV a cette ligne maintenant: 


Listing 1.30 : GCC 4.8.1 sans optimisation + objdump 


4005a4: d2800000 mov x0, #0x0 // #0 


LDP (Load Pair) remet les registres X29 et X30. 


Il n'y a pas de point d'exclamation aprés l'instruction: celui signifie que les valeurs 
sont d’abord chargées depuis la pile, et ensuite SP est incrémenté de 16. Cela est 
appelé post-index. 


Une nouvelle instruction est apparue en ARM64: RET. Elle fonctionne comme BX LR, 
un hint bit particulier est ajouté, qui informe le CPU qu'il s'agit d'un retour de fonction, 
et pas d'une autre instruction de saut, et il peut l'exécuter de maniére plus optimale. 


A cause de la simplicité de la fonction, GCC avec l'option d'optimisation génére le 
méme code. 


1.5.4 MIPS 
Un mot à propos du «pointeur global » 


Un concept MIPS important est le «pointeur global». Comme nous le savons déjà, 
chaque instruction MIPS a une taille de 32-bit, donc il est impossible d'avoir une 
adresse 32-bit dans une instruction: il faut pour cela utiliser une paire. (comme le 
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fait GCC dans notre exemple pour le chargement de l'adresse de la chaíne de texte). 
Il est possible, toutefois, de charger des données depuis une adresse dans l'inter- 
val register — 32768...register + 32767 en utilisant une seule instruction (car un offset 
signé de 16 bits peut étre encodé dans une seule instruction). Nous pouvons alors 
allouer un registre dans ce but et dédier un bloc de 64KiB pour les données les plus 
utilisées. Ce registre dédié est appelé un «pointeur global » et il pointe au milieu du 
bloc de 64 KiB. Ce bloc contient en général les variables globales et les adresses 
des fonctions importées, comme printf(), car les développeurs de GCC ont déci- 
dé qu'obtenir l'adresse d'une fonction devait se faire en une instruction au lieu de 
deux. Dans un fichier ELF ce bloc de 64KiB se trouve en partie dans une section .sbss 
(«small BSS? ») pour les données non initialisées et .sdata («small data ») pour celles 
initialisées. Cela implique que le programmeur peut choisir quelle donnée il/elle sou- 
haite rendre accessible rapidement et doit les stocker dans .sdata/.sbss. Certains 
programmeurs old-school peuvent se souvenir du modéle de mémoire MS-DOS 11.7 
on page 1297 ou des gestionnaires de mémoire MS-DOS comme XMS/EMS oü toute 
la mémoire était divisée en bloc de 64KiB. 


Ce concept n'est pas restreint à MIPS. Au moins les PowerPC utilisent aussi cette 
technique. 

GCC avec optimisation 

Considérons l'exemple suivant, qui illustre le concept de «pointeur global ». 


Listing 1.31 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


$LCO: 
; \000 est l'octet à zéro en base octale: 
.ascii "Hello, world!\012\000" 


main: 
; prologue de la fonction. 
; définir GP: 


lui $28,%hi( gnu local gp) 

addiu $sp,$sp,-32 

addiu  $28,$28,%lo(_ gnu local gp) 
; sauver RA sur la pile locale: 


SW $31,28($sp) 
; charger l'adresse de la fonction puts() dans $25 depuis GP: 
lw $25,%call16(puts) ($28) 
; charger l'adresse de la chaíne de texte dans $4 ($a0): 
lui $4,%hi($LCO) 
; sauter à puts(), en sauvant l'adresse de retour dans le register link: 
jalr $25 


addiu $4,$4,%lo($LC0) ; slot de retard de branchement 
; restaurer RA: 


lw $31,28($sp) 

; copier 0 depuis $zero dans $v0: 
move $2,$0 

; retourner en sautant à la valeur dans RA: 
j $31 


; épilogue de la fonction: 


^3Block Started by Symbol 
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addiu $sp,$sp,32 ; slot de retard de branchement + libérer la pile 
locale 


Comme on le voit, le registre $GP est défini dans le prologue de la fonction pour 
pointer au milieu de ce bloc. Le registre RA est sauvé sur la pile locale. puts() est 
utilisé ici au lieu de printf (). L'adresse de la fonction puts() est chargée dans $25 
en utilisant l'instruction LW («Load Word»). Ensuite l'adresse de la chaine de texte 
est chargée dans $4 avec la paire d'instructions LUI ((«Load Upper Immediate ») et 
ADDIU («Add Immediate Unsigned Word »). LUI défini les 16 bits de poids fort du 
registre (d'oü le mot «upper» dans le nom de l'instruction) et ADDIU ajoute les 16 
bits de poids faible de l'adresse. 


ADDIU suit JALR (vous n'avez pas déjà oublié le slot de délai de branchement ?). Le 
registre $4 est aussi appelé $A0, qui est utilisé pour passer le premier argument 
d'une fonction ^^. 


JALR («Jump and Link Register») saute à l'adresse stockée dans le registre $25 
(adresse de puts()) en sauvant l'adresse de la prochaine instruction (LW) dans RA. 
C'est trés similaire à ARM. Oh, encore une chose importante, l'adresse sauvée dans 
RA n'est pas l'adresse de l'instruction suivante (car c'est celle du s/ot de délai et 
elle est exécutée avant l'instruction de saut), mais l'adresse de l'instruction aprés la 
suivante (aprés le slot de délai). Par conséquent, PC +8 est écrit dans RA pendant 
l'exécution de JALR, dans notre cas, c'est l'adresse de l'instruction LW aprés ADDIU. 


LW («Load Word ») à la ligne 20 restaure RA depuis la pile locale (cette instruction 
fait partie de l'épilogue de la fonction). 


MOVE à la ligne 22 copie la valeur du registre $0 ($ZERO) dans $2 ($VO). 


MIPS a un registre constant, qui contient toujours zéro. Apparemment, les dévelop- 
peurs de MIPS avaient à l'esprit que zéro est la constante la plus utilisée en program- 
mation, utilisons donc le registre $0 à chaque fois que zéro est requis. 


Un autre fait intéressant est qu'il manque en MIPS une instruction qui transfére 
des données entre des registres. En fait, MOVE DST, SRC est ADD DST, SRC, $ZERO 
(DST = SRC +0), qui fait la méme chose. Manifestement, les développeurs de MIPS 
voulaient une table des opcodes compacte. Cela ne signifie pas qu'il y a une ad- 
dition à chaque instruction MOVE. Trés probablement, le CPU optimise ces pseudo- 
instructions et l'UAL?? n'est jamais utilisé. 


J à la ligne 24 saute à l'adresse dans RA, qui effectue effectivement un retour de 
la fonction. ADDIU aprés J est en fait exécutée avant J (vous vous rappeler du slot 
de délai de branchement ?) et fait partie de l'épilogue de la fonction. Voici un listing 
généré par IDA. Chaque registre a son propre pseudo nom: 


Listing 1.32 : GCC 4.4.5 avec optimisation (IDA) 


.text:00000000 main: 
.text:00000000 
.text:00000000 var 10 
.text:00000000 var 4 
.text:00000000 


-0x10 
-4 


441 a table des registres MIPS est disponible en appendice .3.1 on page 1352 
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; prologue de la fonction. 


; définir GP: 

.text:00000000 lui $gp, ( gnu local gp >> 16) 
.text:00000004 addiu $sp, -0x20 

.text:00000008 la $gp, (gnu local gp € OxFFFF) 
; sauver RA sur la pile locale: 

.text:0000000C SW $ra, Ox20+var 4($sp) 


; sauver GP sur la pile locale: 
; pour une raison, cette instruction manque dans la sortie en assembleur de 


text :00000010 sw $gp, 0x20-var 10($sp) 

; charger l'adresse de la fonction puts() dans $9 depuis GP: 

.text:00000014 lw $t9, (puts & OxFFFF) ($gp) 

; générer l'adresse de la chaíne de texte dans $a0: 

.text:00000018 lui $a0, ($LCO >> 16) # "Hello, world!" 

; sauter à puts(), en sauvant l'adresse de retour dans le register link: 

.text:0000001C jalr $t9 

.text:00000020 la $a0, ($LCO & OxFFFF) £ "Hello, 
world!" 

; restaurer RA: 

.text:00000024 lw $ra, Ox20+var 4($sp) 

; copier 0 depuis $zero dans $v0: 

.text:00000028 move $vO, $zero 

; retourner en sautant à la valeur dans RA: 

.text:0000002C jr $ra 

; épilogue de la fonction: 

.text:00000030 addiu $sp, 0x20 


L'instruction à la ligne 15 sauve la valeur de GP sur la pile locale, et cette instruction 
manque mystérieusement dans le listing de sortie de GCC, peut-étre une erreur de 
GCC ^5, La valeur de GP doit effectivement être sauvée, car chaque fonction utilise 
sa propre fenétre de 64KiB. Le registre contenant l'adresse de puts() est appelé 
$T9, car les registres préfixés avec T- sont appelés «temporaires » et leur contenu 
ne doit pas étre préservé. 


GCC sans optimisation 
GCC sans optimisation est plus verbeux. 


Listing 1.33 : GCC 4.4.5 sans optimisation (résultat en sortie de l'assembleur) 


© © CO) - OY UI un 


m 


$LCO: 
.ascii "Hello, world!\012\000" 
main: 
; prologue de la fonction. 
; sauver RA ($31) et FP sur la pile: 
addiu $sp,$sp, -32 
SW $31,28($sp) 
SW $fp,24($sp) 
; définir le pointeur de pile FP (stack frame pointer): 
move $fp,$sp 


46Apparemment, les fonctions générant les listings ne sont pas si critique pour les utilisateurs de GCC, 
donc des erreurs peuvent toujours subsister. 
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définir GP: 
lui $28,%hi( gnu local gp) 
addiu $28,$28,%lo(_ gnu local gp) 
charger l'adresse de la chaîne de texte: 
lui $2,%h1i($LCO) 
addiu $4,$2,%lo($LC0) 
charger l'adresse de puts() en utilisant GP: 
lw $2, %call16(puts) ($28) 
nop 
appeler puts(): 
move $25,$2 
jalr $25 
nop ; slot de retard de branchement 


restaurer GP depuis la pile locale: 


lw $28,16($fp) 
; mettre le registre $2 ($V0) à zéro: 
move $2,$0 


; épilogue de la fonction. 
restaurer SP: 

move $sp,$fp 
; restaurer RA: 


lw $31,28($sp) 
; restaurer FP: 
lw $fp,24($sp) 


addiu — $sp,$sp,32 
; sauter en RA: 
j $31 
nop ; slot de délai de branchement 


Nous voyons ici que le registre FP est utilisé comme un pointeur sur la pile. Nous 
voyons aussi 3 NOPs. Le second et le troisiéme suivent une instruction de branche- 
ment. Peut-étre que le compilateur GCC ajoute toujours des NOPs (à cause du slot de 
retard de branchement) aprés les instructions de branchement, et, si l'optimisation 
est demandée, il essaye alors de les éliminer. Donc, dans ce cas, ils sont laissés en 
place. 


Voici le listing IDA : 
Listing 1.34 : GCC 4.4.5 sans optimisation (IDA) 


.text:00000000 main: 
.text:00000000 


.text:00000000 var 10 - -0x10 

.text:00000000 var 8 - -8 

.text:00000000 var 4 = -4 

. text: 00000000 

; prologue de la fonction. 

; sauver RA et FP sur la pile: 

.text:00000000 addiu $sp, -0x20 
.text:00000004 SW $ra, Ox20+var 4($sp) 
. text: 00000008 SW $fp, 0x20+var_8($sp) 


; définir FP (stack frame pointer): 
.text:0000000C move $fp, $sp 
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; définir GP: 

.text:00000010 la $gp, gnu local gp 

.text:00000018 SW $gp, 0x20+var_10($sp) 

; charger l'adresse de la chaîne de texte: 

.text:0000001C lui $v0, (aHelloWorld >> 16) # "Hello, 
pu 

text: 00000020 addiu  $a0, $v0, (aHelloWorld € OxFFFF) # 


"Hello, world!" 
; charger l'adresse de puts() en utilisant GP: 


.text:00000024 lw $vO, (puts € OxFFFF) ($gp) 
.text:00000028 or $at, $zero ; NOP 

; appeler puts(): 

.text:0000002C move $t9, $v0 

.text:00000030 jalr $t9 

.text:00000034 or $at, $zero ; NOP 

; restaurer GP depuis la pile locale: 

.text:00000038 lw $gp, Ox20+var 10($fp) 

; mettre le registre $2 ($V0) à zéro: 

.text:0000003C move $v0, $zero 


; épilogue de la fonction. 
; restaurer SP: 


.text:00000040 move $sp, $fp 

; restaurer RA: 

.text:00000044 lw $ra, Ox20+var 4($sp) 
; restaurer FP: 

.text:00000048 lw $fp, Ox20+var 8($sp) 
.text:0000004C addiu $sp, 0x20 

; sauter en RA: 

.text:00000050 jr $ra 

.text:00000054 or $at, $zero ; NOP 


Intéressant, IDA a reconnu les instructions LUI/ADDIU et les a agrégées en une pseu- 
do instruction LA («Load Address ») à la ligne 15. Nous pouvons voir que cette pseudo 
instruction a une taille de 8 octets! C'est une pseudo instruction (ou macro) car ce 
n'est pas une instruction MIPS réelle, mais plutót un nom pratique pour une paire 
d'instructions. 


Une autre chose est qu'IDA ne reconnait pas les instructions NOP, donc ici elles 
se trouvent aux lignes 22, 26 et 41. C'est OR $AT, $ZERO. Essentiellement, cette 
instruction applique l'opération OR au contenu du registre $AT avec zéro, ce qui, 
bien sür, est une instruction sans effet. MIPS, comme beaucoup d'autres ISAs, n'a 
pas une instruction NOP. 


Róle de la pile dans cet exemple 


L'adresse de la chaîne de texte est passée dans le registre. Pourquoi définir une pile 
locale quand méme? La raison de cela est que la valeur des registres RA et GP doit 
être sauvée quelque part (car printf() est appelée), et que la pile locale est utilisée 
pour cela. Si cela avait été une fonction leaf, il aurait été possible de se passer du 
prologue et de l'épilogue de la fonction, par exemple: 1.4.3 on page 11. 


GCC avec optimisation : chargeons-le dans GDB 
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Listing 1.35 : extrait d'une session GDB 


root@debian-mips:~# gcc hw.c -03 -o hw 


root@debian-mips:~# gdb hw 
GNU gdb (GDB) 7.0.1-debian 


Reading symbols from /root/hw...(no debugging symbols found)...done. 
(gdb) b main 

Breakpoint 1 at 0x400654 

(gdb) run 

Starting program: /root/hw 


Breakpoint 1, 0x00400654 in main () 
(gdb) set step-mode on 


(gdb) disas 

Dump of assembler code for function main: 
0x00400640 <main+0>: lui gp, 0x42 
0x00400644 <main+4>: addiu sp,sp,-32 
0x00400648 <main+8>: addiu gp,gp,-30624 
0x0040064c <main+12>: SW ra,28(sp) 
0x00400650 <main+16>: sw gp, 16(sp) 
0x00400654 <main+20>: lw t9, -32716(gp) 
0x00400658 <main+24>: lui a0,0x40 


0x0040065c <main+28>: jalr t9 
0x00400660 <main+32>: addiu a0,a0,2080 


0x00400664 <main+36>: lw ra,28(sp) 
0x00400668 <main+40>: move v0,zero 
0x0040066c <main+44>: jr ra 


0x00400670 <main+48>: addiu sp,sp,32 
End of assembler dump. 

(gdb) s 

0x00400658 in main () 

(gdb) s 

0x0040065c in main () 

(gdb) s 

Ox2ab2de60 in printf () from /lib/libc.so.6 
(gdb) x/s $a0 

0x400820: "hello, world" 

(gdb) 


1.5.5 Conclusion 


La différence principale entre le code x86/ARM et x64/ARM64 est que le pointeur sur 
la chaíne a une taille de 64 bits. Le fait est que les CPUs modernes sont maintenant 
64-bit a cause le la baisse du coút de la mémoire et du grand besoin de cette derniére 
par les applications modernes. Nous pouvons ajouter bien plus de mémoire a nos 
ordinateurs que les pointeurs 32-bit ne peuvent en adresser. Ainsi, tous les pointeurs 
sont maintenant 64-bit. 
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1.5.6 Exercices 


e http://challenges. re/48 
e http://challenges. re/49 


1.6 Fonction prologue et épilogue 


Un prologue de fonction est une séquence particuliére d'instructions située au début 
d'une fonction. Il ressemble souvent à ce morceau de code: 


push ebp 
mov ebp, esp 
sub esp, X 


Ce que ces instructions font: sauvent la valeur du registre EBP dans la pile (push 
ebp), sauvent la valeur actuelle du registre ESP dans le registre EBP (mov ebp, esp) 
et enfin allouent de la mémoire dans la pile pour les variables locales de la fonction 
(sub esp, X). 


La valeur du registre EBP reste la méme durant la période oü la fonction s'exécute 
et est utilisée pour accéder aux variables locales et aux arguments de la fonction. 


Le registre ESP peut aussi étre utilisé pour accéder aux variables locales et aux ar- 
guments de la fonction, cependant cette approche n'est pas pratique car sa valeur 
est susceptible de changer au cours de l'exécution de cette fonction. 


L'épilogue de fonction libére la mémoire allouée dans la pile (mov esp, ebp), restaure 
l'ancienne valeur de EBP précédemment sauvegardée dans la pile (pop ebp) puis 
rend l'exécution à l'appelant (ret 0). 


mov esp, ebp 
pop ebp 
ret 0 


Les prologues et épilogues de fonction sont généralement détectés par les désas- 
sembleurs pour déterminer où une fonction commence et où elle se termine. 


1.6.1 Récursivité 


Les prologues et épilogues de fonction peuvent affecter négativement les perfor- 
mances de la récursion. 


Plus d'information sur la récursivité dans ce livre: 3.7.3 on page 614. 


1.7 Une fonction vide: redux 


Revenons sur l'exemple de la fonction vide 1.3 on page 8. Maintenant que nous 
connaissons le prologue et l'épilogue de fonction, ceci est une fonction vide 1.1 on 
page 8 compilée par GCC sans optimisation: 
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Listing 1.36 : GCC 8.2 x64 sans optimisation (résultat en sortie de l'assembleur) 


f: 
push rbp 
mov rbp, rsp 
nop 
pop rbp 
ret 


C'est RET, mais le prologue et l'épilogue de la fonction, probablement, n'ont pas été 
optimisés et laissés tels quels. NOP semble étre un autre artefact du compilateur. De 
toutes facons, la seule instruction effective ici est RET. Toutes les autres instructions 
peuvent étre supprimées (ou optimisées). 


1.8 Renvoyer des valeurs: redux 


A nouveau, quand on connait le prologue et l'épilogue de fonction, recompilons un 
exemple renvoyant une valeur (1.4 on page 10, 1.8 on page 10) en utilisant GCC 
sans optimisation: 


Listing 1.37 : GCC 8.2 x64 sans optimisation (résultat en sortie de l'assembleur) 


f: 


push rbp 

mov rbp, rsp 
mov eax, 123 
pop rbp 

ret 


Les seules instructions efficaces ici sont MOV et RET, les autres sont - prologue et 
épilogue. 


1.9 Pile 


La pile est une des structures de données les plus fondamentales en informatique 
A AKA® LIFO®. 


Techniquement, il s'agit d'un bloc de mémoire situé dans l'espace d'adressage d'un 
processus et qui est utilisé par le registre ESP en x86, RSP en x64 ou par le registre 
SP en ARM comme un pointeur dans ce bloc mémoire. 


Les instructions d'accés à la pile sont PUSH et POP (en x86 ainsi qu'en ARM Thumb- 
mode). PUSH soustrait à ESP/RSP/SP 4 en mode 32-bit (ou 8 en mode 64-bit) et 
écrit ensuite le contenu de l'opérande associé à l'adresse mémoire pointée par 
ESP/RSP/SP. 


^'wikipedia.org/wiki/Call stack 
^8 Also Known As — Aussi connu sous le nom de 
49Dernier entré, premier sorti 
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POP est l'opération inverse: elle récupére la donnée depuis l'adresse mémoire poin- 
tée par SP, l'écrit dans l'opérande associé (souvent un registre) puis ajoute 4 (ou 8) 
au pointeur de pile. 


Aprés une allocation sur la pile, le pointeur de pile pointe sur le bas de la pile. PUSH 
décrémente le pointeur de pile et POP l'incrémente. 


Le bas de la pile représente en réalité le début de la mémoire allouée pour le bloc 
de pile. Cela semble étrange, mais c'est comme ca. 


ARM supporte à la fois les piles ascendantes et descendantes. 


Par exemple les instructions STMFD/LDMFD, STMED??/LDMED?! sont utilisées pour 
gérer les piles descendantes (qui grandissent vers le bas en commencant avec une 
adresse haute et évoluent vers une plus basse). 


Les instructions STMFA??/LDMFA??, STMEA?^/LDMEA?? sont utilisées pour gérer les 
piles montantes (qui grandissent vers les adresses hautes de l'espace d'adressage, 
en commengant avec une adresse située en bas de l'espace d'adressage). 


1.9.1 Pourquoi la pile grandit en descendant? 


Intuitivement, on pourrait penser que la pile grandit vers le haut, i.e. vers des adresses 
plus élevées, comme n'importe qu'elle autre structure de données. 


La raison pour laquelle la pile grandit vers le bas est probablement historique. Dans 
le passé, les ordinateurs étaient énormes et occupaient des piéces entiéres, il était 
facile de diviser la mémoire en deux parties, une pour le tas et une pour la pile. 
Évidemment, on ignorait quelle serait la taille du tas et de la pile durant l'exécution 
du programme, donc cette solution était la plus simple possible. 


Début du heap Début de la pile 


Heap — <— Pile 


Dans [D. M. Ritchie and K. Thompson, The UNIX Time Sharing System, (1974)]°°on 
peut lire: 


The user-core part of an image is divided into three logical seg- 
ments. The program text segment begins at location 0 in the virtual 


50Store Multiple Empty Descending (instruction ARM) 
51Load Multiple Empty Descending (instruction ARM) 
52Store Multiple Full Ascending (instruction ARM) 
53Load Multiple Full Ascending (instruction ARM) 
54Store Multiple Empty Ascending (instruction ARM) 
55Load Multiple Empty Ascending (instruction ARM) 
56 Aussi disponible en URL 
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address space. During execution, this segment is write-protected and 
a single copy of it is shared among all processes executing the same 
program. At the first 8K byte boundary above the program text seg- 
ment in the virtual address space begins a nonshared, writable data 
segment, the size of which may be extended by a system call. Starting 
at the highest address in the virtual address space is a pile segment, 
which automatically grows downward as the hardware's pile pointer 
fluctuates. 


Cela nous rappelle comment certains étudiants prennent des notes pour deux cours 
différents dans un seul et méme cahier en prenant un cours d'un cóté du cahier, 
et l'autre cours de l'autre cóté. Les notes de cours finissent par se rencontrer à un 
moment dans le cahier quand il n'y a plus de place. 


1.9.2 Quel est le róle de la pile? 
Sauvegarder l'adresse de retour de la fonction 


x86 


Lorsque l'on appelle une fonction avec une instruction CALL, l'adresse du point exac- 
tement aprés cette derniére est sauvegardée sur la pile et un saut inconditionnel à 
l'adresse de l'opérande CALL est exécuté. 


L'instruction CALL est équivalente à la paire d'instructions 
PUSH address after call / JMP operand. 


RET va chercher une valeur sur la pile et y saute —ce qui est équivalent à la paire 
d'instructions POP tmp / JMP tmp. 


Déborder de la pile est trés facile. Il suffit de lancer une récursion éternelle: 


void f() 
1 


T3 


MSVC 2008 signale le probléme: 


c:\tmp6>cl ss.cpp /Fass.asm 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 7 
y 80x86 

Copyright (C) Microsoft Corporation. All rights reserved. 


SS.Cpp 
c:\tmp6\ss.cpp(4) : warning C4717: 'f' : recursive on all control paths, 7 
y function will cause runtime stack overflow 


... Mais génère tout de méme le code correspondant: 
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?F@@YAXXZ PROC ERE 
; Line 2 

push ebp 

mov ebp, esp 
; Line 3 

call ? F@@YAXXZ "eo 
; Line 4 

pop ebp 

ret 0 
?fF@@YAXXZ ENDP T 


...Si nous utilisons l'option d'optimisation du compilateur (option /0x) le code optimi- 
sé ne va pas déborder de la pile et au lieu de cela va fonctionner correctemment?’ : 


?F@@YAXXZ PROC sf 
: Line 2 
$LL3@f : 
: Line 3 

jmp SHORT $LL3@f 
?F@@YAXXZ ENDP nw 


GCC 4.4.1 génére un code similaire dans les deux cas, sans, toutefois émettre d'aver- 
tissement à propos de ce probléme. 


ARM 


Les programmes ARM utilisent également la pile pour sauver les adresses de retour, 
mais différemment. Comme mentionné dans «Hello, world! » (1.5.3 on page 25), RA 
est sauvegardé dans LR (link register). Si l'on a toutefois besoin d'appeler une autre 
fonction et d'utiliser le registre LR une fois de plus, sa valeur doit étre sauvegardée. 
Usuellement, cela se fait dans le prologue de la fonction. 


Souvent, nous voyons des instructions comme PUSH R4-R7,LR en méme temps que 
cette instruction dans l'épilogue POP R4-R7,PC—ces registres qui sont utilisés dans 
la fonction sont sauvegardés sur la pile, LR inclus. 


Néanmoins, si une fonction n'appelle jamais d'autre fonction, dans la terminologie 
RISC elle est appelée fonction leaf??. Ceci a comme conséquence que les fonctions 
leaf ne sauvegardent pas le registre LR (car elles ne le modifient pas). Si une telle 
fonction est petite et utilise un petit nombre de registres, elle peut ne pas utiliser du 
tout la pile. Ainsi, il est possible d'appeler des fonctions leaf sans utiliser la pile. Ce 
qui peut étre plus rapide sur des vieilles machines x86 car la mémoire externe n'est 
pas utilisée pour la pile °°. Cela peut être utile pour des situations où la mémoire 
pour la pile n'est pas encore allouée ou disponible. 


57ironique ici 

58infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13785.html 

3911 y a quelque temps, sur PDP-11 et VAX, l'instruction CALL (appel d'autres fonctions) était coû- 
teuse; jusqu’a 50% du temps d’exécution pouvait étre passé a ¢a, il était donc considéré qu’avoir un 
grand nombre de petites fonctions était un anti-pattern [Eric S. Raymond, The Art of UNIX Programming, 
(2003)Chapter 4, Part 11]. 
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Quelques exemples de fonctions leaf: 1.14.3 on page 140, 1.14.3 on page 141, 1.281 
on page 405, 1.297 on page 428, 1.28.5 on page 428, 1.191 on page 274, 1.189 on 
page 271, 1.208 on page 295. 


Passage des arguments d'une fonction 


Le moyen le plus utilisé pour passer des arguments en x86 est appelé «cdecl » : 


push arg3 

push arg2 

push argl 

call f 

add esp, 12 ; 4*3-12 


La fonction appelée recoit ses arguments par la pile. 


Voici donc comment sont stockés les arguments sur la pile avant l'exécution de la 
premiére instruction de la fonction f() : 


ESP return address 
ESP+4 argument£1, marqué dans IDA comme arg_0 
ESP+8 argument£2, marqué dans IDA comme arg 4 


ESP+0xC | argument£3, marqué dans IDA comme arg 8 


Pour plus d'information sur les conventions d'appel, voir cette section (6.1 on page 953). 


À propos, la fonction appelée n'a aucune d'information sur le nombre d'arguments 
qui ont été passés. Les fonctions C avec un nombre variable d'arguments (comme 
printf ()) peuvent déterminer leur nombre en utilisant les spécificateurs de la chaîne 
de format (qui commencent pas le symbole 96). 


Si nous écrivons quelque comme: 


printf("sd %d %d", 1234); 


printf() va afficher 1234, et deux autres nombres aléatoires*, qui sont situés à 
cóté dans la pile. 


C'est pourquoi la facon dont la fonction main() est déclarée n'est pas trés impor- 
tante: comme main(), 
main(int argc, char *argv[]) oumain(int argc, char *argv[], char *envp[]). 


En fait, le code-CRT appelle main(), schématiquement, de cette facon: 


push envp 
push argv 
push argc 
call main 


60pas aléatoire dans le sens strict du terme, mais plutôt imprévisibles: ?? on page?? 
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Si vous déclarez main() comme main() sans argument, ils sont néanmoins tou- 
jours présents sur la pile, mais ne sont pas utilisés. Si vous déclarez main() as 
comme main(int argc, char *argv[]), vous pourrez utiliser les deux premiers 
arguments, et le troisième restera «invisible » pour votre fonction. Il est même pos- 
sible de déclarer main() comme main(int argc), cela fonctionnera. 


Un autre exemple apparenté: 6.1.10. 
Autres facons de passer les arguments 


Il est à noter que rien n'oblige les programmeurs à passer les arguments à travers 
la pile. Ce n'est pas une exigence. On peut implémenter n'importe quelle autre mé- 
thode sans utiliser du tout la pile. 


Une méthode répandue chez les débutants en assembleur est de passer les argu- 
ments par des variables globales, comme: 


Listing 1.38 : Code assembleur 


mov X, 123 

mov Y, 456 

call do something 
X dd ? 
Y dd ? 
do something proc near 

; take X 

; take Y 

; do something 

retn 


do something endp 


Mais cette méthode a un inconvénient évident: la fonction do something() ne peut 
pas s'appeler elle- méme récursivement (ou par une autre fonction), car il faudrait 
écraser ses propres arguments. La méme histoire avec les variables locales: si vous 
les stockez dans des variables globales, la fonction ne peut pas s'appeler elle-méme. 
Et ce n'est pas thread-safe ®t. Une méthode qui stocke ces informations sur la pile 
rend cela plus facile—elle peut contenir autant d'arguments de fonctions et/ou de 
valeurs, que la pile a d'espace. 


[Donald E. Knuth, The Art of Computer Programming, Volume 1, 3rd ed., (1997), 
189] mentionne un schéma encore plus étrange, particuliérement pratique sur les 
IBM System/360. 


61Correctement implémenté, chaque thread aurait sa propre pile avec ses propres arguments/variables. 
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MS-DOS a une maniére de passer tous les arguments de fonctions via des registres, 
par exemple, c'est un morceau de code pour un ancien MS-DOS 16-bit qui affiche 
“Hello, world!": 


mov dx, msg ; address of message 

mov ah, 9 ; 9 means "print string" function 
int 21h ; DOS "syscall" 

mov ah, 4ch ; "terminate program" function 
int 21h ; DOS "syscall" 

msg db ‘Hello, World!\$' 


C'est presque similaire à la méthode 6.1.3 on page 955. Et c'est aussi trés similaire 
aux appels systémes sous Linux (6.3.1 on page 973) et Windows. 


Si une fonction MS-DOS devait renvoyer une valeur booléenne (i.e., un simple bit, 
souvent pour indiquer un état d'erreur), le flag CF était souvent utilisé. 


Par exemple: 


mov ah, 3ch ; create file 
lea dx, filename 

mov cl, 1 

int 21h 

jc error 

mov file handle, ax 


error: 


En cas d'erreur, le flag CF est mis. Sinon, le handle du fichier nouvellement créé est 
retourné via AX. 


Cette méthode est encore utilisée par les programmeurs en langage d'assemblage. 
Dans le code source de Windows Research Kernel (qui est trés similaire à Windows 
2003) nous pouvons trouver quelque chose comme ca (file base/ntos/ke/i386/cpu.asm) : 


public Get386Stepping 
Get386Stepping proc 
call MultiplyTest ; Perform multiplication test 
jnc short G3s00 ; if nc, muttest is ok 
mov ax, 0 
ret 
G3s00: 
call Check386B0 ; Check for BO stepping 
jnc short G3s05 ; if nc, it's Bl/later 
mov ax, 100h ; It is B0/earlier stepping 
ret 
G3s05: 
call Check386D1 ; Check for D1 stepping 
jc short G3s10 ; if c, it is NOT D1 
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mov ax, 301h ; It is D1/later stepping 
ret 

G3s10: 
mov ax, 101h ; assume it is Bl stepping 
ret 


MultiplyTest proc 


xor CX,CX ; 64K times is a nice round number 
mlt00: push Cx 
call Multiply ; does this chip's multiply work? 
pop CX 
jc short mltx ; if c, No, exit 
loop mlt00 ; if nc, YEs, loop to try again 
clc 
mltx: 
ret 


MultiplyTest endp 


Stockage des variables locales 


Une fonction peut allouer de l'espace sur la pile pour ses variables locales simple- 
ment en décrémentant le pointeur de pile vers le bas de la pile. 


Donc, c'est trés rapide, peu importe combien de variables locales sont définies. Ce 
n'est pas une nécessité de stocker les variables locales sur la pile. Vous pouvez les 
stocker oü bon vous semble, mais c'est traditionnellement fait comme cela. 


x86: alloca() function 


Intéressons-nous à la fonction alloca() 9? 


Cette fonction fonctionne comme malloc(), mais alloue de la mémoire directement 
sur la pile. L'espace de mémoire ne doit pas étre libéré via un appel à la fonction 
free(), puisque l'épilogue de fonction (1.6 on page 41) remet ESP à son état initial 
ce qui va automatiquement libérer cet espace mémoire. 


Intéressons-nous à l'implémentation d'alloca(). Cette fonction décale simplement 
ESP du nombre d'octets demandé vers le bas de la pile, faisant ESP sur le bloc alloué. 


Essayons : 


#ifdef | GNUC __ 
#include «alloca.h» // GCC 
#else 


$2Avec MSVC, l'implémentation de cette fonction peut étre trouvée dans les fichiers allocal6.asm et 
chkstk.asm dans 
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\intel 
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#include <malloc.h> // MSVC 
Hendif 
#include <stdio.h> 


void f() 


{ 

char *buf=(char*)alloca (600); 
#ifdef | GNUC __ 

snprintf (buf, 600, "hi! %d, %d, %d\n", 1, 2, 3); // GCC 
#else 

_snprintf (buf, 600, "hi! %d, %d, %d\n", 1, 2, 3); // MSVC 
Hendif 


puts (buf); 
}; 


La fonction snprintf() fonctionne comme printf(), mais au lieu d'afficher le 
résultat sur la sortie standard (ex., dans un terminal ou une console), il l'écrit dans 
le buffer buf. La fonction puts() copie le contenu de buf dans la sortie standard. 
Évidemment, ces deux appels de fonctions peuvent être remplacés par un seul appel 
à la fonction printf (), mais nous devons illustrer l'utilisation de petit buffer. 


MSVC 


Compilons (MSVC 2010) : 
Listing 1.39 : MSVC 2010 


mov eax, 600 ; 00000258H 


call alloca probe 16 
mov esi, esp 

push 3 

push 2 

push 1 

push OFFSET $5G2672 
push 600 ; 00000258H 
push esi 

call snprintf 

push esi 

call | puts 


add esp, 28 


Le seul argument d'alloca() est passé via EAX (au lieu de le mettre sur la pile) °°. 


63C'est parce que alloca() est plutót une fonctionnalité intrinséque du compilateur (11.4 on page 1290) 
qu'une fonction normale. Une des raisons pour laquelle nous avons besoin d'une fonction séparée au lieu 
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GCC + Syntaxe Intel 


GCC 4.4.1 fait la méme chose sans effectuer d'appel á des fonctions externes : 


Listing 1.40 : GCC 4.7.3 


.LC0: 
.String "hi! %d, %d, %d\n" 
f? 
push ebp 
mov ebp, esp 
push ebx 
sub esp, 660 
lea ebx, [esp+39] 
and ebx, -16 ; align pointer by 16-byte border 
mov DWORD PTR [esp], ebx ; S 
mov DWORD PTR [esp+20], 3 
mov DWORD PTR [esp+16], 2 
mov DWORD PTR [esp+12], 1 
mov DWORD PTR [esp+8], OFFSET FLAT:.LCO ; "hi! %d, %d, “din” 
mov DWORD PTR [esp+4], 600 ; maxlen 
call _snprintf 
mov DWORD PTR [esp], ebx ; sS 
call puts 
mov ebx, DWORD PTR [ebp-4] 
leave 
ret 


GCC + Syntaxe AT&T 


Voyons le même code mais avec la syntaxe AT&T : 


Listing 1.41 : GCC 4.7.3 


.LC0: 
.string "hi! %d, %d, %d\n" 


pushl %ebp 
movl “esp, %ebp 
pushl %ebx 
subl $660, %esp 


leal 39(%esp), %ebx 
andl $-16, %ebx 
movl *sebx, (%esp) 
movl $3, 20(%esp) 
movl $2, 16(%esp) 
movl $1, 12(%esp) 
movl $.LCO, 8(%esp) 


de quelques instructions dans le code, et parce que l'implémentation d'alloca() par MSVC® a également 
du code qui lit depuis la mémoire récemment allouée pour laisser l'OS mapper la mémoire physique vers 
la VMS. Aprés l'appel à la fonction alloca(), ESP pointe sur un bloc de 600 octets que nous pouvons 
utiliser pour le tableau buf. 
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movl $600, 4(%esp) 


call _snprintf 

movl %ebx, (%esp) 
call puts 

movl -4(%ebp), %ebx 
leave 

ret 


Le code est le méme que le précédent. 


Au fait, movl $3, 20(%esp) correspond à mov DWORD PTR [esp+20], 3 avec la syn- 
taxe intel. Dans la syntaxe AT&T, le format registre+offset pour l'adressage mémoire 
ressemble à offset(%register). 


(Windows) SEH 

Les enregistrements SEHSS sont aussi stockés dans la pile (s'ils sont présents). Lire 
à ce propos: (6.5.3 on page 996). 

Protection contre les débordements de tampon 


Lire à ce propos (1.26.2 on page 350). 


Dé-allocation automatique de données dans la pile 


Peut-étre que la raison pour laquelle les variables locales et les enregistrements SEH 
sont stockés dans la pile est qu'ils sont automatiquement libérés quand la fonction se 
termine en utilisant simplement une instruction pour corriger la position du pointeur 
de pile (souvent ADD). Les arguments de fonction sont aussi désalloués automati- 
quement à la fin de la fonction. À l'inverse, toutes les données allouées sur le heap 
doivent étre désallouées de facon explicite. 


1.9.3 Une disposition typique de la pile 


Une disposition typique de la pile dans un environnement 32-bit au début d'une 
fonction, avant l'exécution de sa premiére instruction ressemble à ceci: 


ESP-OxC | variable locale: 2, marqué dans IDA comme var 8 


ESP-8 variable locale#1, marqué dans IDA comme var 4 
ESP-4 valeur enregistrée deEBP 

ESP Adresse de retour 

ESP+4 argument#1, marqué dans IDA comme arg_0 
ESP+8 argument#2, marqué dans IDA comme arg 4 


ESP+0xC | argument£3, marqué dans IDA comme arg 8 


66Structured Exception Handling 
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1.9.4 Bruit dans la pile 


Quand quelqu'un dit que quelques chose est 
aléatoire, ce que cela signifie en pratique 
c'est qu'il n'est pas capable de voir les 
régularités de cette chose 


Stephen Wolfram, A New Kind of Science. 
Dans ce livre les valeurs dites «bruitée » ou «poubelle » présente dans la pile ou dans 
la mémoire sont souvent mentionnées. 


D'oü viennent-elles? Ces valeurs ont été laissées sur la pile aprés l'exécution de 
fonctions précédentes. Par exemple: 


#include <stdio.h> 


void f1() 
{ 
int a=1, b=2, c=3; 
}; 
void f2() 
1 
int a, b, C; 
printf ("*sd, %d, %d\n", a, b, c); 
}; 
int main() 
1 
f1(); 
f2(); 
}; 
Compilons ... 

Listing 1.42 : sans optimisation MSVC 2010 
$SG2752 DB '%d, %d, %d', OaH, OOH 
_c$ = -12 ; size = 4 
_b$ = -8 ; size = 4 
_a$ = -4 ; size = 4 
_f1 PROC 

push ebp 

mov ebp, esp 

sub esp, 12 

mov DWORD PTR a$[ebp], 1 
mov DWORD PTR _b$[ebp], 2 
mov DWORD PTR c$[ebp], 3 
mov esp, ebp 

pop ebp 

ret 0 


E ENDP 
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_c$ = -12 ; size = 4 
_b$ = -8 ; size = 4 
_a$ = -4 ; size = 4 
_f2 PROC 
push ebp 
mov ebp, esp 
sub esp, 12 
mov eax, DWORD PTR c$[ebp] 
push eax 
mov ecx, DWORD PTR _b$[ebp] 
push ecx 
mov edx, DWORD PTR a$[ebp] 
push edx 
push OFFSET $5G2752 ; '%d, %d, %d' 
call DWORD PTR . imp printf 
add esp, 16 
mov esp, ebp 
pop ebp 
ret 0 
E ENDP 
_main PROC 
push ebp 
mov ebp, esp 
call _f1 
call _f2 
xor eax, eax 
pop ebp 
ret 0 
main  ENDP 


Le compilateur va rouspéter un peu... 


c:\Polygon\c>cl st.c /Fast.asm /MD 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 7 
S 80x86 

Copyright (C) Microsoft Corporation. All rights reserved. 


st.c 

c:\polygon\c\st.c(11) : warning C4700: uninitialized local variable 'c' 7 
V used 

c:\polygon\c\st.c(11) : warning C4700: uninitialized local variable 'b' 7 
y used 

c:\polygon\c\st.c(11) : warning C4700: uninitialized local variable 'a' 7 
y used 


Microsoft (R) Incremental Linker Version 10.00.40219.01 
Copyright (C) Microsoft Corporation. All rights reserved. 


/out:st.exe 
st.obj 


Mais quand nous lancons le programme compilé ... 
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c:\Polygon\c>st 
1, 2, 3 


Quel résultat étrange! Aucune variables n'a été initialisées dans f2(). Ce sont des 
valeurs «fantómes » qui sont toujours dans la pile. 


56 


Chargeons cet exemple dans OllyDbg : 


MOU EBP,ESP 
SUB ESP, ØC 
MOV DWORD PTR SS:CLOCAL.1],1 
MOV DWORD PTR SS:CLOCAL.2],2 
MOU DWORD PTR SS: CLOCAL.3],3 


io c c c 


lz] 
PUSH EBP > B12CIB1B : 
SUB ESPOC. 5 à ES Goss Sobit OLEFFFFFEF) 
FU EAX, DWORD PTR SS: CLOCAL.31 Se debit DLFFFFFFEF) 
sal - MOU ECX, DWORD PTR a dpi o EN 
ESP=00/FFSee —— rng 


(NO, NB, NE, A, 


FFFFFFFET» 
Gannia MS, O| RETURN from s 


st.@12C 


st.B12C 
M 


C9 Co Co C PO 


coc 
Seoene 


© 


(e cocoC 
oc 


oo 
S 


Fig. 1.6: OllyDbg : f1() 


Quand f1() assigne les variable a, 6 et c, leurs valeurs sont stockées à l'adresse 
Ox1FF860 et ainsi de suite. 
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Et quand f2() s'exécute: 


OllyDbg - st.exe 


Ele View Debug Trace Plugins Options Windows Help 
ax] ml >| tt > +9) 0] Ju] 1Je/mw)T|c/R/../k] Bim) Hl iz 
CPU - main thread, module st (Of xl 


a z S3EC ac SUB ESP, ØC 
a 8B45 F4 MOV EAX, DWORD PTR SS:CLOCAL.3] 


5a PUSH ERX 

8B4D F8 MOV ECX,DWORD PTR SS: CLOCAL.2] 
51 PUSH ECX 

popp FC MOY, FDX, DWORD PTR SS: [LOCAL. 1] 
63 Qüpa2cal | PUSH OFFSET 012CB000 

ES 25000608 |CALL 61201061 

3304 18 ADD ESP, 10 = A 
MOU ESP,EBP EIP B12C1026 st.612C1026 


ES O(FFFFFFFF) 
aL FFFFFFFF) 


@( FFFFFFFF) 
Bt FFFFFFFF) 
7EFDDaBat FFF) 


5 De 
Stack [MM1FFS581=3 TO atFFFFFFFF) 
EAX=000C2880 T 


hs 


FFFFFFFE[w 
AMS, O| RETURN from st.@12C 
an + 


+, O| RETURN from st.B12C 


*B|RETURN from st.@12C 
v 


Fig. 1.7: OllyDbg : f2() 


... a, b et c de la fonction f2() sont situées à la méme adresse! Aucunes autre fonc- 
tion n'a encore écrasées ces valeurs, elles sont donc encore inchangées. Pour que 
cette situation arrive, il faut que plusieurs fonctions soit appelées les unes aprés les 
autres et que SP soit le méme à chaque début de fonction (i.e., les fonctions doivent 
avoir le máme nombre d'arguments). Les variables locales seront donc positionnées 
au méme endroit dans la pile. Pour résumer, toutes les valeurs sur la pile sont des 
valeurs laissées par des appels de fonction précédents. Ces valeurs laissées sur la 
pile ne sont pas réellement aléatoires dans le sens strict du terme, mais elles sont 
imprévisibles. Y a t'il une autre option? Il serait probablement possible de nettoyer 
des parties de la pile avant chaque nouvelle exécution de fonction, mais cela engen- 
drerait du travail et du temps d'exécution (non nécessaire) en plus. 


MSVC 2013 


Cet exemple a été compilé avec MSVC 2010. Si vous essayez de compiler cet exemple 
avec MSVC 2013 et de l'exécuter, ces 3 nombres seront inversés: 


c:\Polygon\c>st 
3, 2, 1 


Pourquoi? J’ai aussi compilé cet exemple avec MSVC 2013 et constaté ceci: 


Listing 1.43 : MSVC 2013 
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_a$ = -12 ; size = 4 
_b$ = -8 ; size = 4 
_c$ = -4 ; size = 4 
f2 PROC 
f2 ENDP 
_c$ = -12 ; size = 4 
_b$ = -8 ; size = 4 
_a$ = -4 ; size = 4 
f1 PROC 
_f1 ENDP 


Contrairement à MSVC 2010, MSVC 2013 alloue les variables a/b/c dans la fonction 
f2() dans l'ordre inverse puisqu'il se comporte différemment en raison d'un change- 
ment supposé dans son fonctionnement interne.Ceci est correct, car le standard du 
C/C++ n'a aucune règle sur l'ordre d'allocation des variables locales sur la pile. 


1.9.5 Exercices 


* http://challenges.re/51 
* http://challenges.re/52 


1.10 Fonction presque vide 


Ceci est un morceau de code réel que j'ai trouvé dans Boolector®’ : 


// forward declaration. the function is residing in some other module: 
int boolector main (int argc, char **argv); 


// executable 
int main (int argc, char **argv) 


{ 
} 


return boolector main (argc, argv); 


Pourquoi quelqu'un ferait-il comme ca? Je ne sais pas mais mon hypothése est que 
boolector main() peut étre compilée dans une sorte de DLL ou bibliothéque dyna- 
mique, et appelée depuis une suite de test. Certainement qu’une suite de test peut 
préparer les variables argc/argv comme le ferait CRT. 


Il est intéressant de voir comment c'est compilé: 


87https://boolector.github.io/ 
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Listing 1.44 : GCC 8.2 x64 sans optimisation (résultat en sortie de l'assembleur) 


main: 


push rbp 

mov rbp, rsp 

sub rsp, 16 

mov DWORD PTR -4[rbp], edi 

mov QWORD PTR -16[rbp], rsi 
mov rdx, QWORD PTR -16[rbp] 
mov eax, DWORD PTR -4[rbp] 

mov rsi, rdx 

mov edi, eax 

call boolector main 

leave 

ret 


Ceci est OK, le prologue (non optimisé) déplace inutilement deux arguments, CALL, 
épilogue, RET. Mais regardons la version optimisée: 


Listing 1.45 : GCC 8.2 x64 avec optimisation (résultat en sortie de l'assembleur) 


main: 
jmp boolector main 


Aussi simple que ca: la pile et les registres ne sont pas touchés et boolector main() 
ale méme ensemble d'arguments. Donc, tout ce que nous avons à faire est de passer 
l'exécution à une autre adresse. 


Ceci est proche d'une fonction thunk. 


Nous verons queelque chose de plus avancé plus tard: 1.11.2 on page 75, 1.21.1 on 
page 205. 


1.11 printf() avec plusieurs arguments 


Maintenant, améliorons l'exemple Hello, world! (1.5 on page 12) en remplacant 
printf() dans la fonction main() par ceci: 


#include <stdio.h> 


int main() 

{ 
printf("a=%d; b=%d; c=%d", 1, 2, 3); 
return 0; 


}; 


1.11.1 x86 
X86: 3 arguments entier 


MSVC 
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En le compilant avec MSVC 2010 Express nous obtenons: 


$SG3830 DB 'a=%d; b=%d; c=%d', OOH 
push 3 
push 2 
push 1 
push OFFSET $5G3830 
call _printf 
add esp, 16 ; 00000010H 


Presque la méme chose, mais maintenant nous voyons que les arguments de printf () 
sont poussés sur la pile en ordre inverse. Le premier argument est poussé en dernier. 


À propos, dans un environnement 32-bit les variables de type int ont une taille de 
32-bit. ce qui fait 4 octets. 


Donc, nous avons 4 arguments ici. 4+ 4 = 16 —ils occupent exactement 16 octets 
dans la pile: un pointeur 32-bit sur une chaíne et 3 nombres de type int. 


Lorsque le pointeur de pile (registre ESP) est re-modifié par l'instruction ADD ESP, X 
aprés un appel de fonction, souvent, le nombre d'arguments de la fonction peut-étre 
déduit en divisant simplement X par 4. 


Bien sûr, cela est spécifique à la convention d'appel cdecl, et seulement pour un 
environnement 32-bit. 


Voir aussi la section sur les conventions d'appel (6.1 on page 953). 


Dans certains cas, plusieurs fonctions se terminent les une aprés les autres, le com- 
pilateur peut concaténer plusieurs instructions «ADD ESP, X» en une seule, aprés le 
dernier appel: 


push al 
push a2 
call ... 
push al 
call ... 
push al 
push a2 
push a3 


call ... 
add esp, 24 


Voici un exemple réel: 


Listing 1.46 : x86 


.text:100113E7 push 3 

.text:100113E9 call sub 100018B0 ; prendre un argument (3) 
.text:100113EE call sub 100019D0 ; ne prendre aucun argument 
.text:100113F3 call sub 10006490 ; ne prendre aucun argument 
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.text:100113F8 push 1 

.text:100113FA call sub 100018B0 ; prendre un argument (1) 

.text:100113FF add esp, 8 ; supprimer deux arguments de la pile 
à la fois 
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MSVC et OllyDbg 


Maintenant, essayons de charger cet exemple dans OllyDbg. C'est l'un des débug- 
gers en espace utilisateur win32 les plus populaire. Nous pouvons compiler notre 
exemple avec l'option /MD de MSVC 2012, qui signifie lier avec MSVCR*.DLL, ainsi 
nous verrons clairement les fonctions importées dans le debugger. 


Ensuite chargeons l'exécutable dans OllyDbg. Le tout premier point d'arrét est dans 
ntdll.dll, appuyez sur F9 (run). Le second point d'arrét est dans le code CRT. Nous 
devons maintenant trouver la fonction main(). 


Trouvez ce code en vous déplacant au tout début du code (MSVC alloue la fonction 
main() au tout début de la section de code) : 


CPU - main thread, module 1 [Of x! 
a 55 


PUSH EBP Registers (FPU) 
FOU FBP ESP 6A3ES634 MSUCR11B.—initenv 
BATES GOSECE 1 8 


PUSH 1 eee 
PUSH OFFSET 612F3000 SP @022F93C 


CALL DWORD PTR DS:[<&MSUCR110.printf>] E 

ADD ESP, 18 

XOR EAX, EAX Er perde E 

POP EBP 

C3 RETN 

de: 3900 Gana! CHP WORD PTR DS: ESTRUCT IMRGE DOS. HERD a PSS SE 

74 04 JE SHORT_912F 1020 = Da Sa maed Pie dadladaa, 

SOR EAX, EAX _ 1 B jit B(FFFFFFFF) 
D Le - Sø FSO jit PEFDD@GG( FFF) 

o 650 @(FFFFFFFF) 


"ve 


astErr 00000900 ERR 
246 (NO,NB,E,BE, 


| Address [Hex dump — — — ^ — 1  — — — — [asCII (ANSI a 
B12 61 5 64) 3 2 B 20/62 a b 
Da 
C DD 
a| 81 B6 BS 9F SB 


aa aa 66 66 aa 


a1 
F 
a 

4 

4 


ao aa 6a ea 

aa a aa aa 

aa a aa aa 
00/00 aa GG 00/60 aao oo aO 
a Qao aa 00 00/00 AA AA HA 


Fig. 1.8: OllyDbg : le tout début de la fonction main() 


Clickez sur l'instruction PUSH EBP, pressez F2 (mettre un point d'arrét) et pressez F9 
(lancer le programme). Nous devons effectuer ces actions pour éviter le code CRT, 
car il ne nous intéresse pas pour le moment. 
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Presser F8 (enjamber) 6 fois, i.e. sauter 6 instructions: 


main thread, module 1 


PUSH EBP 
MOU EBP,ESP 
PUSH 3 


68 gaspar eh PUSH OFFSET 012F3000 

FF15 96262F6 CALL DWORD PTR DS: [<8MSUCR110.printf>1 

8304 16 ADD ESP, 10 

3300 XOR EAX, EAX 

5D POP EBP ER 

c3 RETN EIP G12F1GGE 1.012F100E 

ES 4D5A0000 | NOU EAX, SA4D C 0 ES 002B 32 BtFFFFFFFF) 

66:3905 000A] CMP WORD PTR_DS: [<STRUCT IMRGE, DOS HERD P1 G(FFFFFFFF) 
JE SHORT B12F182D A à BLEFFFFFFF) 

XOR EAX, EAX OLFFFFFFFF) 


4 Li HO né a = a 
DF (HSUCRI18.pr Dee ones nee oit id 


Err ERROR_SUCCESS 
6 (NO,NB,E,BE,NS,PE,GE,LE) 


Fig. 1.9: OllyDbg : avant l'exécution de printf () 


Maintenant le PC pointe vers l'instruction CALL printf. OllyDbg, comme d'autres 
debuggers, souligne la valeur des registres qui ont changé. Donc, chaque fois que 
vous appuyez sur F8, EIP change et sa valeur est affichée en rouge. ESP change 
aussi, car les valeurs des arguments sont poussées sur la pile. 


Oü sont les valeurs dans la pile? Regardez en bas à droite de la fenétre du debugger: 


£ 070| ASCII "a 
k 
£ 
£ 


2| Ab6j| RETURN from MSUCR110. 6A2FFFAF 4. 
Y JT TET £t 


8 
iau LA 
B12F121C|L$/6| RETURN from 1.612F1000 to 1.8 
| r 60668881) 6 
DOSB9FBS|3 AL 
3|| BOSBCE1S| trl 


Fig. 1.10: OllyDbg : pile aprés que les valeurs des arguments aient été poussées (Le 
rectangle rouge a été ajouté par l'auteur dans un éditeur graphique) 


Nous pouvons voir 3 colonnes ici: adresse dans la pile, valeur dans la pile et quelques 
commentaires additionnels d'OllyDbg. OllyDbg peut détecter les pointeurs sur des 
chaines ASCII dans la pile, donc il rapporte la chaine de printf() ici. 


Il est possible de faire un clic-droit sur la chaine de format, cliquer sur «Follow in 
dump », et la chaine de format va apparaitre dans la fenétre en bas à gauche du 
debugger. qui affiche toujours des parties de la mémoire. Ces valeurs en mémoire 
peuvent étre modifiées. Il est possible de changer la chaine de format, auquel cas le 
résultat de notre exemple sera différent. Cela n'est pas trés utile dans le cas présent, 
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mais ce peut-étre un bon exercice pour commencer á comprendre comment tout 
fonctionne ici. 
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Appuyer sur F8 (enjamber). 


Nous voyons la sortie suivante dans la console: 


a=1; b=2; c-3 


Regardons comment les registres et la pile ont changés: 


CPU - main thread, module 1 la x| 
a ^ 


PUSH EBP Registers (FPU) 
MOU, EBP, ESP EAX O ue 
PUSH 3 SAS6EES? MSUCRI 10. 6RS6EESS 


PUSH 1 z 
PUSH OFFSET 012F3000 m WR doc WE E 
2822260) CALL DWORD PTR DS: [<8NSUCR110.printf>] : FIR O RCTI a ie 
ADD ESP, 10 
XOR EAX, EAX 
POP EBP m 
C3 RETN 1.612F1614 
B8 4osaggea |MOU EAX, Sado ed CA 
66:3905 4000] CMP WORD PTR DS: [<STRUCT IMRGE DOS HERD ce e rit BIFFFEFFFE) 
74 ü4 JE SHORT BI2F182D Aen ME Ar dale, 
XOR EAX, EAX 9026 32bit ØLFFFFFFFF) 

D Q = = S ø 7EFDD@GG( FFF) 


Inm-00000010 (decimal 16.7 $8 OES bese enr g 
ESP=0022F928, PTR to ASCII "a-zd; b=%d; o=%d" id: BEFEFFEPEES 


Fig. 1.11: OllyDbg aprés l'exécution de printf() 


Le registre EAX contient maintenant 0xD (13). C'est correct, puisque printf() ren- 
voie le nombre de caractéres écrits. La valeur de EIP a changé: en effet, il contient 
maintenant l'adresse de l'instruction venant aprés CALL printf. Les valeurs de ECX 
et EDX ont également changé. Apparemment, le mécanisme interne de la fonction 
printf() les a utilisés pour dans ses propres besoins. 


Un fait trés important est que ni la valeur de ESP, ni l'état de la pile n'ont été changés! 
Nous voyons clairement que la chaine de format et les trois valeurs correspondantes 
sont toujours là. C'est en effet le comportement de la convention d'appel cdecl : l'ap- 
pelée ne doit pas remettre ESP à sa valeur précédente. L'appelant est responsable 
de le faire. 
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Appuyer sur F8 à nouveau pour exécuter l'instruction ADD ESP, 10: 


PUSH EBP 
MOU EBP,ESP 
PUSH 3 
PUSH 2 


PUSH 1 
PUSH OFFSET 012F3000 
CALL DWORD PTR DS: [<2MSUCR110.printf>] 
ADD ESP, 1 
XOR EAX, EAX 
POP EBP 
RETN 
MOU EAX, 5A4D CO ES 06 O(FFFFFFFF) 
5 6000] CMP WORD PTR DS:L«STRUCT IMRGE DOS HERD ; jit OLFFFFFFFF) 
JE SHORT_012F1620 -- 0 jit BLEFFFFFFF) 
XOR EAX EAX oo 0028 32bit ØLFFFFFFFF) 
ME SHORT Q s SB jit 7EFDDOBBLFFF) 
Q GS B02B @(FFFFFFFF) 


7 1.612F1617 


Fig. 1.12: OllyDbg : aprés l'exécution de l'instruction ADD ESP, 10 


ESP a changé, mais les valeurs sont toujours dans la pile! Oui, bien sûr; il n'y a pas 
besoin de mettre ces valeurs a zéro ou quelque chose comme ca. Tout ce qui se 
trouve au dessus du pointeur de pile (SP) est du bruit ou des déchets et n'a pas du 
tout de signification. Ca prendrait beaucoup de temps de mettre a zéro les entrées 
inutilisées de la pile, et personne n'a vraiment besoin de le faire. 


GCC 


Maintenant, compilons la méme programme sous Linux en utilisant GCC 4.4.1 et 
regardons ce que nous obtenons dans IDA: 


main proc near 


var_10 dword ptr -10h 


var_C = dword ptr -0Ch 

var 8 - dword ptr -8 

var 4 - dword ptr -4 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 10h 
mov eax, offset aADBDCD ; "a=%d; b=%d; c=%d" 
mov [esp+10h+var_4], 3 
mov [esp+10h+var_8], 2 
mov [esp+10h+var_C], 1 


mov [esp+10h+var_10], eax 
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call _ printf 
mov eax, 0 
leave 
retn 

main endp 


Il est visible que la différence entre le code MSVC et celui de GCC est seulement dans 
la maniére dont les arguments sont stockés sur la pile. Ici GCC manipule directement 
la pile sans utiliser PUSH/POP. 


GCC et GDB 
Essayons cet exemple dans GDB*? sous Linux. 


L'option -g indique au compilateur d'inclure les informations de debug dans le fichier 
exécutable. 


$ gcc 1.c -g -o 1 


$ gdb 1 
GNU gdb (GDB) 7.6.1-ubuntu 


Reading symbols from /home/dennis/polygon/1...done. 


Listing 1.47 : let's set breakpoint on printf() 


(gdb) b printf 
Breakpoint 1 at 0x80482f0 


Lancons le programme. Nous n'avons pas la code source de la fonction printf() ici, 
donc GDB ne peut pas le montrer, mais pourrait. 


(gdb) run 
Starting program: /home/dennis/polygon/1 


Breakpoint 1, _ printf (format=0x80484f0 "a-*d; b=%d; c-*d") at printf.c:29 
29 printf.c: No such file or directory. 


Afficher 10 éléments de la pile. La colonne la plus à gauche contient les adresses de 
la pile. 


(gdb) x/10w $esp 


Oxbffffllc: 0x0804844a 0x080484f0 0x00000001 0x00000002 
Oxbffff12c: 0x00000003 0x08048460 0x00000000 0x00000000 
Oxbffff13c: 0xb7e29905 0x00000001 


Le tout premier élément est la RA (0x0804844a). Nous pouvons le vérifier en désas- 
semblant la mémoire à cette adresse: 


68GNU Debugger 
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(gdb) x/5i 0x0804844a 
0x804844a <main+45>: mov $0x0,%eax 
0x804844f <main+50>: leave 
0x8048450 <main+51>: ret 
0x8048451: xchg %ax,%ax 
0x8048453: xchg %ax,%ax 


Les deux instructions XCHG sont des instructions sans effet, analogues à NOPs. 
Le second élément (0x080484f0) est l'adresse de la chaîne de format: 


(gdb) x/s 0x080484f0 
0x80484f0: "a=%d; b=%d; c=%d" 


Les 3 éléments suivants (1, 2, 3) sont les arguments de printf(). Le reste des 
éléments sont juste des «restes» sur la pile, mais peuvent aussi étre des valeurs 
d’autres fonctions, leurs variables locales, etc. Nous pouvons les ignorer pour le 
moment. 


Lancer la commande «finish ». Cette commande ordonne a GDB d’«exécuter toutes 
les instructions jusqu’a la fin de la fonction ». Dans ce cas: exécuter jusqu’a la fin de 
printf(). 


(gdb) finish 

Run till exit from #0 — printf (format=0x80484f0 "a=%d; b=%d; c=%d") at 2 
y printf.c:29 

main () at 1.c:6 

6 return 0; 

Value returned is $2 = 13 


GDB montre ce que printf () a renvoyé dans EAX (13). C'est le nombre de caractères 
écrits, exactement comme dans l'exemple avec OllyDbg. 


Nous voyons également «return 0; » et l'information que cette expression se trouve 
a la ligne 6 du fichier 1.c. En effet, le fichier 1.c se trouve dans le répertoire cou- 
rant, et GDB y a trouvé la chaine. Comment est-ce que GDB sait quelle ligne est 
exécutée à un instant donné? Cela est du au fait que lorsque le compilateur génére 
les informations de debug, il sauve également une table contenant la relation entre 
le numéro des lignes du code source et les adresses des instructions. GDB est un 
debugger niveau source, aprés tout. 


Examinons les registres. 13 in EAX : 


(gdb) info registers 


eax Oxd 13 
ecx 0x0 0 
edx 0x0 0 
ebx 0xb7fc0000 -1208221696 
esp Oxbffff120 Oxbffff120 
ebp Oxbffff138 Oxbffff138 
esi 0x0 0 
edi 0x0 0 


eip 0x804844a 0x804844a <main+45> 
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Désassemblons les instructions courantes. La fleche pointe sur la prochaine instruc- 
tion qui sera exécutée. 


(gdb) disas 
Dump of assembler code for function main: 


0x0804841d <+0>: push X *sebp 

0x0804841e <+1>: mov *sesp , sebp 
0x08048420 «4-3»: and Soxfffffff0,%esp 
0x08048423 <+6>: sub $0x10,%esp 
0x08048426 <+9>: movl $0x3,0xc(%esp) 
0x0804842e «417»: movl $0x2,0x8 (%esp) 


0x08048436 <+25>: movl $0x1,0x4(%esp) 
0x0804843e <+33>: movl $0x80484f0, (%esp) 


0x08048445 <+40>: call 0x80482f0 <printf@plt> 
=> 0x0804844a <+45>: mov $0x0,%eax 

0x0804844f <+50>: leave 

0x08048450 <+51>: ret 


End of assembler dump. 


GDB utilise la syntaxe AT&T par défaut. Mais il est possible de choisir la syntaxe Intel: 


(gdb) set disassembly-flavor intel 
(gdb) disas 
Dump of assembler code for function main: 


0x0804841d <+0>: push ebp 

0x0804841e «41»: mov ebp,esp 

0x08048420 «43»: and esp,0xfffffffo 

0x08048423 <+6>: sub esp,0x10 

0x08048426 <+9>: mov DWORD PTR [esp+0xc],0x3 

0x0804842e <+17>: mov DWORD PTR [esp+0x8] , 0x2 

0x08048436 <+25>: mov DWORD PTR [esp+0x4] , 0x1 

0x0804843e <+33>: mov DWORD PTR [esp] ,0x80484f0 

0x08048445 <+40>: call 0x80482f0 <printf@plt> 
=> 0x0804844a <+45>: mov eax,0x0 

0x0804844f «450»: leave 

0x08048450 «451»: ret 


End of assembler dump. 


Exécuter la ligne suivante de code C/C++. GDB montre une parenthése fermante, 
signifiant la fin du bloc. 


(gdb) step 
7 }; 


Examinons les registres aprés l'exécution de l'instruction MOV EAX, 0. En effet, EAX 
est à zéro à ce stade. 


(gdb) info registers 

eax 0x0 0 
ecx 0x0 0 
edx 0x0 0 
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ebx 0xb7fc0000 -1208221696 
esp Oxbffff120 Oxbffff120 
ebp Oxbffff138 Oxbffff138 
esi 0x0 0 
edi 0x0 0 


eip 0x804844f 0x804844f <main+50> 


x64: 8 arguments entier 


Pour voir comment les autres arguments sont passés par la pile, changeons encore 
notre exemple en augmentant le nombre d'arguments à 9 (chaine de format de 
printf() + 8 variables int) : 


#include <stdio.h> 


int main() 
{ 
printf("a=%d; b=%d; c=%d; d-*sd; e=%d; f=%d; g=%d; h=%d\n", 1, 2, 3,7 
S 4, 5, 6, 7, 8); 
return 0; 


}; 


MSVC 


Comme il a déjà été mentionné, les 4 premiers arguments sont passés par les re- 
gistres RCX, RDX, R8, R9 sous Win64, tandis les autres le sont—par la pile. C'est exac- 
tement de que l'on voit ici. Toutefois, l'instruction MOV est utilisée ici à la place de 
PUSH, donc les valeurs sont stockées sur la pile d'une maniére simple. 


Listing 1.48 : MSVC 2012 x64 


$SG2923 DB 'a-*sd; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d', OaH, 00H 
main PROC 
sub rsp, 88 
mov DWORD PTR [rsp+64], 8 
mov DWORD PTR [rsp+56], 7 
mov DWORD PTR [rsp+48], 6 
mov DWORD PTR [rsp+40], 5 
mov DWORD PTR [rsp+32], 4 
mov rod, 3 
mov r8d, 2 
mov edx, 1 
lea rcx, OFFSET FLAT: $SG2923 


call printf 


; renvoyer 0 
xor eax, eax 
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add rsp, 88 
ret 0 

main ENDP 

TEXT ENDS 


END 


Le lecteur observateur pourrait demander pourquoi 8 octets sont alloués sur la pile 
pour les valeurs int, alors que 4 suffisent? Oui, il faut se rappeler: 8 octets sont 
alloués pour tout type de données plus petit que 64 bits. Ceci est instauré pour 
des raisons de commodités: cela rend facile le calcul de l'adresse de n'importe quel 
argument. En outre, ils sont tous situés à des adresses mémoires alignées. Il en est 
de méme dans les environnements 32-bit: 4 octets sont réservés pour tout types de 
données. 


GCC 


Le tableau est similaire pour les OS x86-64 *NIX, excepté que les 6 premiers argu- 
ments sont passés par les registres RDI, RSI, RDX, RCX, R8, R9. Tout les autres— par 
la pile. GCC génére du code stockant le pointeur de chaine dans EDI au lieu de RDI— 
nous l'avons noté précédemment: 1.5.2 on page 22. 


Nous avions également noté que le registre EAX a été vidé avant l'appel à printf(): 
1.5.2 on page 22. 


Listing 1.49 : GCC 4.4.6 x64 avec optimisation 


.LC0: 

.String "a=%d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d\n" 
main: 

sub rsp, 40 

mov rod, 5 

mov r8d, 4 

mov ecx, 3 

mov edx, 2 

mov esi, 1 

mov edi, OFFSET FLAT: .LCO 

xor eax, eax ; nombre de registres vectoriels 

mov DWORD PTR [rsp+16], 8 

mov DWORD PTR [rsp+8], 7 

mov DWORD PTR [rsp], 6 


call printf 
; renvoyer 0 
xor eax, eax 


add rsp, 40 
ret 
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GCC + GDB 


Essayons cet exemple dans GDB. 


$ gcc -g 2.c -0 2 


$ gdb 2 
GNU gdb (GDB) 7.6.1-ubuntu 


Reading symbols from /home/dennis/polygon/2...done. 


Listing 1.50 : mettons le point d'arrét à printf(), et lancons 


(gdb) b printf 

Breakpoint 1 at 0x400410 

(gdb) run 

Starting program: /home/dennis/polygon/2 


Breakpoint 1, _ printf (format=0x400628 "a=%d; b=%d; c=%d; d=%d; e=%d; f-*d» 
V ; g=%d; h=%d\n") at printf.c:29 
29 printf.c: No such file or directory. 


Les registres RSI/RDX/RCX/R8/R9 ont les valeurs attendues. RIP contient l'adresse de 
la toute premiére instruction de la fonction printf(). 


(gdb) info registers 


rax 0x0 0 

rbx 0x0 0 

rcx 0x3 3 

rdx 0x2 2 

rsi 0x1 1 

rdi 0x400628 4195880 

rbp Ox7fffffffdf60 Ox7fffffffdf60 
rsp Ox7fffffffdf38 Ox7fffffffdf38 
r8 0x4 4 

ro 0x5 5 

r10 Ox7fffffffdceO 140737488346336 
r11 Ox7ffff7a65f60 140737348263776 
r12 0x400440 4195392 

r13 Ox7fffffffeO040 140737488347200 
r14 0x0 0 

r15 0x0 0 


rip Ox7ffff7a65f60 | Ox7ffff7a65f60 < printf> 


Listing 1.51 : inspectons la chaîne de format 


(gdb) x/s $rdi 
0x400628: "a-*sd; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d\n" 


Affichons la pile avec la commande x/g cette fois—g est l'unité pour giant words, i.e., 
mots de 64-bit. 
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(gdb) x/10g $rsp 


Ox7fffffffdf38: 0x0000000000400576 0x0000000000000006 
Ox7fffffffdf48: 0x0000000000000007 0x00007fff(90000008 
Ox7fffffffdf58: 0x0000000000000000 0x0000000000000000 
Ox7fffffffdf68: 0x00007ffff7a33de5 0x0000000000000000 
Ox7fffffffdf78: 0x00007fffffffeO48 0x0000000100000000 


Le tout premier élément de la pile, comme dans le cas précédent, est la RA. 3 valeurs 
sont aussi passées par la pile: 6, 7, 8. Nous voyons également que 8 est passé 
avec les 32-bits de poids fort non effacés: 0x00007f f f00000008. C'est en ordre, car 
les valeurs sont d'un type int, qui est 32-bit. Donc, la partie haute du registre ou 
l'élément de la pile peuvent contenir des «restes de données aléatoires ». 


Si vous regardez où le contrôle reviendra aprés l'exécution de printf(), GDB affiche 
la fonction main() en entier: 


(gdb) set disassembly-flavor intel 
(gdb) disas 0x0000000000400576 
Dump of assembler code for function main: 


0x000000000040052d «40»: push rbp 

0x000000000040052e <+1>: mov rbp, rsp 
0x0000000000400531 <+4>: sub rsp,0x20 
0x0000000000400535 <+8>: mov DWORD PTR [rsp+0x10],0x8 


0x000000000040053d <+16>: mov DWORD PTR [rsp+0x8],0x7 
0x0000000000400545 <+24>: mov DWORD PTR [rsp],0x6 
0x000000000040054c <+31>: mov r9d,0x5 
0x0000000000400552 <+37>: mov r8d,0x4 
0x0000000000400558 <+43>: mov ecx, 0x3 
0x000000000040055d «448»: mov edx, 0x2 
0x0000000000400562 «453»: mov esi,0x1 
0x0000000000400567 «458»: mov edi,0x400628 
0x000000000040056c «463»: mov eax,0x0 


0x0000000000400571 «468»: call 0x400410 <printf@plt> 
0x0000000000400576 <+73>: mov eax,0x0 
0x000000000040057b <+78>: leave 

0x000000000040057c <+79>: ret 


End of assembler dump. 


Laissons se terminer l'exécution de printf(), exécutez l'instruction mettant EAX 
à zéro, et notez que le registre EAX à une valeur d'exactement zéro. RIP pointe 
maintenant sur l'instruction LEAVE, i.e, la pénultiéme de la fonction main(). 


(gdb) finish 
Run till exit from #0 | printf (format=0x400628 "a=%d; b=%d; c=%d; d-*d; e 
V =%d; f=%d; g=%d; h=%d\n") at printf.c:29 
b=2; c=3; d=4; e=5; f=6; g=7; h=8 
() at 2.c:6 
return 0; 
Value returned is $1 - 39 
(gdb) next 
7 un 
(gdb) info registers 
rax 0x0 0 
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rbx 0x0 0 

rcx 0x26 38 

rdx Ox7ffff7dd59f0 140737351866864 
rsi Ox7fffffd9 2147483609 

rdi 0x0 0 

rbp Ox7fffffffdf60 | Ox7fffffffdf60 
rsp Ox7fffffffdf40 Ox7fffffffdf40 
r8 Ox7ffff7dd26a0 140737351853728 
r9 Ox7ffff7a60134 140737348239668 
r10 Ox7fffffffd5bO 140737488344496 
r11 Ox7ffff7a95900 140737348458752 
r12 0x400440 4195392 

r13 Ox7fffffffe040 140737488347200 
r14 0x0 0 

r15 0x0 0 

rip 0x40057b 0x40057b <main+78> 
1.11.2 ARM 


ARM: 3 arguments entier 


Le schéma ARM traditionnel pour passer des arguments (convention d'appel) se 
comporte de cette facon: les 4 premiers arguments sont passés par les registres 
RO-R3; les autres par la pile. Cela ressemble au schéma de passage des arguments 
dans fastcall (6.1.3 on page 955) ou win64 (6.1.5 on page 957). 


ARM 32-bit 


sans optimisation Keil 6/2013 (Mode ARM) 


Listing 1.52 : sans optimisation Keil 6/2013 (Mode ARM) 


.text:00000000 main 
.text:00000000 10 40 2D E9 STMFD SP!, {R4,LR} 


.text:00000004 03 30 A0 E3 MOV R3, #3 

.text:00000008 02 20 A0 E3 MOV R2, #2 

.text:0000000C 01 10 AO E3 MOV R1, #1 

.text:00000010 08 00 8F E2 ADR RO, aADBDCD "a=%d; b=%d; c=%d" 
.text:00000014 06 00 00 EB BL _ 2printf 


.text:00000018 00 00 AO E3 MOV RO, +0 ; renvoyer 60 
.text:0000001C 10 80 BD E8  LDMFD  SP!, {R4,PC} 


Donc, les 4 premiers arguments sont passés par les registres RO-R3 dans cet ordre: 
un pointeur sur la chaîne de format de printf() dans RO, puis 1 dans R1, 2 dans R2 
et 3 dans R3. L'instruction en 0x18 écrit O dans RO—c’est la déclaration C de return 
0. 


avec optimisation Keil 6/2013 génére le méme code. 
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avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.53 : avec optimisation Keil 6/2013 (Mode Thumb) 


.text:00000000 main 


.text:00000000 10 B5 PUSH {R4,LR} 
.text:00000002 03 23 MOVS R3, #3 

.text:00000004 02 22 MOVS — R2, #2 

.text:00000006 01 21 MOVS R1, #1 

.text:00000008 02 AO ADR RO, aADBDCD ; "a=%d; b=%d; c=%d" 
.text:0000000A 00 FO OD F8 BL __2printf 

.text:0000000E 00 20 MOVS RO, #0 

.text:00000010 10 BD POP (RA, PC) 


Il n'y a pas de différence significative avec le code non optimisé pour le mode ARM. 
avec optimisation Keil 6/2013 (Mode ARM) + supprimons le retour 


Retravaillons légèrement l'exemple en supprimant return 0 : 


#include <stdio.h> 


void main() 


{ 
}; 


printf("a=%d; b=%d; c=%d", 1, 2, 3); 


Le résultat est quelque peu inhabituel: 


Listing 1.54 : avec optimisation Keil 6/2013 (Mode ARM) 


.text:00000014 main 


.text:00000014 03 30 A0 E3 MOV R3, #3 

.text:00000018 02 20 A0 E3 MOV R2, #2 

.text:0000001C 01 10 AO E3 MOV R1, #1 

.text:00000020 1E OE 8F E2 ADR RO, aADBDCD ; 'a-*d; b=%d; c=%d\n" 
.text:00000024 CB 18 00 EA B . 2printf 


C'est la version optimisée (-03) pour le mode ARM et cette fois nous voyons B comme 
derniére instruction au lieu du BL habituel. Une autre différence entre cette version 
optimisée et la précédente (compilée sans optimisation) est l'absence de fonctions 
prologue et épilogue (les instructions qui préservent les valeurs des registres RO et 
LR). L'instruction B saute simplement à une autre adresse, sans manipuler le registre 
LR, de facon similaire au JMP en x86. Pourquoi est-ce que fonctionne? Parce ce code 
est en fait bien équivalent au précédent. Il y a deux raisons principales: 1) Ni la pile 
ni SP (pointeur de pile) ne sont modifiés; 2) l'appel à printf() est la dernière instruc- 
tion, donc il ne se passe rien aprés. A la fin, la fonction printf() rend simplement 
le contróle à l'adresse stockée dans LR. Puisque LR contient actuellement l'adresse 
du point depuis lequel notre fonction a été appelée alors le contróle aprés printf() 
sera redonné à ce point. Par conséquent, nous n'avons pas besoin de sauver LR car 
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il ne nous est pas nécessaire de le modifier. Et il ne nous est non plus pas néces- 
saire de modifier LR car il n'y a pas d'autre appel de fonction excepté printf (). Par 
ailleurs, aprés cet appel nous ne faisons rien d'autre! C'est la raison pour laquelle 
une telle optimisation est possible. 


Cette optimisation est souvent utilisée dans les fonctions où la dernière déclaration 
est un appel à une autre fonction. Un exemple similaire est présenté ici: 1.21.1 on 
page 206. 

Un cas un peu plus simple a été décrit plus haut: 1.10 on page 58. 


ARM64 


GCC (Linaro) 4.9 sans optimisation 


Listing 1.55 : GCC (Linaro) 4.9 sans optimisation 


LCL: 
.string "a=%d; b=%d; c=%d" 
f2: 
; sauver FP et LR sur la pile: 
stp x29, x30, [sp, -16]! 
; définir la pile (FP=SP): 
add x29, sp, 0 
adrp x0, .LC1 
add x0, x0, :lo12:.LC1 
mov wl, 1 
mov w2, 2 
mov w3, 3 
bl printf 
mov w0, 0 
; restaurer FP et LR 
ldp x29, x30, [sp], 16 
ret 


La premiére instruction STP (Store Pair) sauve FP (X29) et LR (X30) sur la pile. 


La seconde instruction, ADD X29, SP, 0 crée la pile. Elle écrit simplement la valeur 
de SP dans X29. 


Ensuite nous voyons la paire d'instructions habituelle ADRP/ADD, qui crée le pointeur 
sur la chaîne. /o12 signifie les 12 bits de poids faible, i.e., le linker va écrire les 12 bits 
de poids faible de l'adresse LC1 dans l'opcode de l'instruction ADD. 1, 2 et 3 sont des 
valeurs int 32-bit, dons elles sont chargées dans les parties 32-bit des registres*? 


GCC (Linaro) 4.9 avec optimisation génére le méme code. 


69Changer 1 par 1L en fera une valeur 64-bit qui sera chargée dans un registres 64-bit. En lire plus sur 
les entiers constants/littéraux: 1, 2. 
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ARM: 3 arguments entier 


Utilisons de nouveau l'exemple avec 9 arguments de la section précédente: 1.11.1 
on page 70. 


#include <stdio.h> 


int main() 
{ 
printf("a=%d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%sd\n", 1, 2, 3,2 
4, 5, 6, 7, 8); 
return 0; 


}; 


avec optimisation Keil 6/2013 : Mode ARM 


. text : 00000028 main 

. text: 00000028 

.text:00000028 var 18 - -0x18 
.text:00000028 var 14 - -0x14 
.text:00000028 var 4 = -4 


.text:00000028 

.text:00000028 04 EO 2D E5 STR LR, [SP,#var 4]! 

.text:0000002C 14 DO 4D E2 SUB SP, SP, 40x14 

.text:00000030 08 30 AO E3 MOV R3, +8 

.text:00000034 07 20 AO E3 MOV R2, #7 

.text:00000038 06 10 AO E3 MOV R1, #6 

.text:0000003C 05 00 AO E3 MOV RO, #5 

.text:00000040 04 CO 8D E2 ADD R12, SP, #0x18+var_14 

.text:00000044 OF 00 8C E8 STMIA R12, {RO-R3} 

.text:00000048 04 00 AO E3 MOV RO, £4 

.text:0000004C 00 00 8D E5 STR RO, [SP,#0x18+var_18] 

.text:00000050 03 30 AO E3 MOV R3, #3 

.text:00000054 02 20 AO E3 MOV R2, #2 

.text:00000058 01 10 AO E3 MOV R1, #1 

.text:0000005C 6E OF 8F E2 ADR RO, aADBDCDDDEDFDGD ; "a=%d; b=%d; c=%d; 
d=%d; e=%d; f=%d; g=%"... 

.text:00000060 BC 18 00 EB BL . 2printf 

.text:00000064 14 DO 8D E2 ADD SP, SP, 40x14 

.text:00000068 04 FO 9D E4 LDR PC, [SP+4+var_4],#4 


Ce code peut étre divisé en plusieurs parties: 
* Prologue de la fonction: 


La toute premiére instruction STR LR, [SP,£var 4]! sauve LR sur la pile, car 
nous allons utiliser ce registre pour l'appel à printf(). Le point d'exclamation 
à la fin indique un pré-index. 


Cela signifie que SP est d'abord décrémenté de 4, et qu'ensuite LR va étre 
sauvé à l'adresse stockée dans SP. C'est similaire à PUSH en x86. Lire aussi à 
ce propos: 1.39.2 on page 568. 
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La seconde instruction SUB SP, SP, #0x14 décrémente SP (le pointeur de pile) 
afin d'allouer 0x14 (20) octets sur la pile. En effet, nous devons passer 5 valeurs 
de 32-bit par la pile à la fonction printf(), et chacune occupe 4 octets, ce qui 
fait exactement 5 « 4 — 20. Les 4 autres valeurs de 32-bit sont passées par les 
registres. 


Passer 5, 6, 7 et 8 par la pile: ils sont stockés dans les registres RO, R1, R2 et R3 
respectivement. 

Ensuite, l'instruction ADD R12, SP, #0x18+var_ 14 écrit l'adresse de la pile ou 
ces 4 variables doivent être stockées dans le registre R12. var 14 est une macro 
d'assemblage, égal à -0x14, créée par IDA pour afficher commodément le code 
accédant à la pile. Les macros var ? générée par IDA reflétent les variables 
locales dans la pile. 


Donc, SP+4 doit étre stocké dans le registre R12. 

L'instruction suivante STMIA R12, RO-R3 écrit le contenu des registres RO-R3 
dans la mémoire pointée par R12. STMIA est l'abréviation de Store Multiple Incre- 
ment After (stocker plusieurs incrémenter aprés). Increment After signifie que 
R12 doit étre incrémenté de 4 aprés l'écriture de chaque valeur d'un registre. 


Passer 4 par la pile: 4 est stocké dans RO et ensuite, cette valeur, avec l'aide 
de 

l'instruction STR RO, [SP,#0x18+var 18] est sauvée dans la pile. var 18 est 
-0x18, donc l'offset est 0, donc la valeur du registre RO (4) est écrite à l'adresse 
écrite dans SP. 


* Passer 1, 2 et 3 par des registres: Les valeurs des 3 premiers nombres (a,b,c) 
(respectivement 1, 2, 3) sont passées par les registres R1, R2 et R3 juste avant 
l'appel de printf(). 


* appel de printf() 


Épilogue de fonction: 


L'instruction ADD SP, SP, 40x14 restaure le pointeur SP à sa valeur précé- 
dente, nettoyant ainsi la pile. Bien sür, ce qui a été stocké sur la pile y reste, 
mais sera récrit lors de l'exécution ultérieure de fonctions. 


L'instruction LDR PC, [SP+4+var 4],#4 charge la valeur sauvée de LR depuis 
la pile dans le registre PC, provoquant ainsi la sortie de la fonction. Il n'y a pas 
de point d'exclamation—effectivement, PC est d'abord chargé depuis l'adresse 
stockées dans SP (4-- var 4 = 4+ (-4) = 0), donc cette instruction est analogue à 
INSLDR PC, [SP], #4), et ensuite SP est incrémenté de 4. II s'agit de post-index"?. 
Pourquoi est-ce qu'IDA affiche l'instruction comme ca? Parce qu'il veut illustrer 
la disposition de la pile et le fait que var 4 est alloué pour sauver la valeur de 
LR dans la pile locale. Cette instruction est quelque peu similaire à POP PC en 
x86". 


70Lire à ce propos: 1.39.2 on page 568. 
7111 est impossible de définir la valeur de IP/EIP/RIP en utilisant POP en x86, mais de toutes façons, 
vous avez le droit de faire l'analogie. 
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avec optimisation Keil 6/2013 : Mode Thumb 


.text:0000001C printf main2 

.text:0000001C 

.text:0000001C var 18 - -0x18 

.text:0000001C var 14 = -0x14 

.text:0000001C var 8 - -8 

.text:0000001C 

.text:0000001C 00 B5 PUSH {LR} 

. text: 0000001E 08 23 MOVS R3, #8 

. text: 00000020 85 BO SUB SP, SP, #0x14 

.text:00000022 04 93 STR R3, [SP,#0x18+var 8] 

. text: 00000024 07 22 MOVS R2, #7 

. text: 00000026 06 21 MOVS R1, #6 

. text: 00000028 05 20 MOVS RO, #5 

.text:0000002A 01 AB ADD R3, SP, #0x18+var_14 

.text:0000002C 07 C3 STMIA  R3!, {RO-R2} 

.text:0000002E 04 20 MOVS RO, #4 

.text:00000030 00 90 STR RO, [SP,#0x18+var_ 18] 

. text: 00000032 03 23 MOVS R3, #3 

. text: 00000034 02 22 MOVS R2, #2 

. text: 00000036 01 21 MOVS R1, #1 

. text: 00000038 AO AO ADR RO, aADBDCDDDEDFDGD ; "a=%d; b=%d; c=%d; 
d=%d; e=%d; f=%d; g=%"... 

.text:0000003A 06 FO D9 F8 BL _ 2printf 

.text:0000003E 

.text:0000003E loc 3E ; CODE XREF: examplel3 f+16 

.text:0000003E 05 BO ADD SP, SP, 40x14 

.text:00000040 00 BD POP {PC} 


La sortie est presque comme dans les exemples précédents. Toutefois, c’est du code 
Thumb et les valeurs sont arrangées différemment dans la pile: 8 vient en premier, 
puis 5, 6, 7 et 4 vient en troisieme. 


avec optimisation Xcode 4.6.3 (LLVM) : Mode ARM 


. text:0000290C | printf main2 

. text:0000290C 

. text:0000290C var 1C = -0x1C 
_ text:0000290C var C = -0xC 


. text:0000290C 

. text:0000290C 80 40 2D E9 STMFD SP!, {R7,LR} 
. text:00002910 0D 70 AO El MOV R7, SP 

. text:00002914 14 DO 4D E2 SUB SP, SP, #0x14 
. text:00002918 70 05 01 E3 MOV RO, #0x1570 
. text:0000291C 07 CO AG E3 MOV R12, #7 

. text:00002920 00 00 40 E3  MOVT RO, #0 

. text:00002924 04 20 AO E3 MOV R2, +4 

. text:00002928 00 00 8F EO ADD RO, PC, RO 

. text:0000292C 06 30 AO E3 MOV R3, #6 

. text:00002930 05 10 AO E3 MOV R1, 45 
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. text:00002934 00 20 8D E5 STR R2, [SP,#0x1C+var_1C] 
_ text:00002938 0A 10 8D E9  STMFA SP, {R1,R3,R12} 

. text:0000293C 08 90 AO E3 MOV R9, #8 

. text:00002940 01 10 AO E3 MOV R1, 41 

. text:00002944 02 20 A0 E3 MOV R2, #2 

. text:00002948 03 30 AO E3 MOV R3, #3 

. text:0000294C 10 90 8D E5 STR R9, [SP,#0x1C+var_C] 
. text:00002950 A4 05 00 EB BL _printf 

. text:00002954 07 DO A0 El MOV SP, R7 

. text:00002958 80 80 BD E8  LDMFD SP!, {R7,PC} 


Presque la méme chose que ce que nous avons déjà vu, avec l'exception de l'ins- 
truction STMFA (Store Multiple Full Ascending), qui est un synonyme de l'instruction 
STMIB (Store Multiple Increment Before). Cette instruction incrémente la valeur du 
registre SP et écrit seulement aprés la valeur registre suivant dans la mémoire, plutót 
que d'effectuer ces deux actions dans l'ordre inverse. 


Une autre chose qui accroche le regard est que les instructions semblent étre arran- 
gées de maniére aléatoire. Par exemple, la valeur dans le registre RO est manipulée 
en trois endroits, aux adresses 0x2918, 0x2920 et 0x2928, alors qu'il serait possible 
de le faire en un seul endroit. 


Toutefois, le compilateur qui optimise doit avoir ses propres raisons d'ordonner les 
instructions pour avoir une plus grande efficacité à l'exécution. 


D'habitude, le processeur essaye d'exécuter simultanément des instructions situées 
cóte à cóte. 

Par exemple, des instructions comme MOVT R0, £0 et ADD RO, PC, RO ne peuvent 
pas étre exécutées simultanément puisqu'elles modifient toutes deux le registre RO. 
D'un autre côté, les instructions MOVT RO, #0 et MOV R2, #4 peuvent être exécutées 
simultanément puisque leurs effets n'interférent pas l'un avec l'autre lors de leurs 
exécution. Probablement que le compilateur essaye de générer du code arrangé de 
cette facon (lorsque c'est possible). 


avec optimisation Xcode 4.6.3 (LLVM) : Mode Thumb-2 


_ text:00002BA0 | printf main2 

_ text:00002BA0 

_ text:00002BA0 var 1C = -0x1C 

_ text:00002BA0 var 18 - -0x18 

_ text:00002BA0 var C = -0xC 

_ text:00002BA0 

. text:00002BA0 80 B5 PUSH {R7,LR} 

. text:00002BA2 6F 46 MOV R7, SP 
__text:00002BA4 85 BO SUB SP, SP, #0x14 
. text:00002BA6 41 F2 D8 20 MOVW RO, #0x12D8 


. text:00002BAA 4F FO 07 OC MOV.W R12, #7 
. text:00002BAE CO F2 00 00 MOVT.W RO, #0 
. text:00002BB2 04 22 MOVS R2, +4 
. text:00002BB4 78 44 ADD RO, PC ; char * 
. text:00002BB6 06 23 MOVS R3, #6 
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. text:00002BB8 05 21 MOVS R1, 45 
. text:00002BBA OD F1 04 OE ADD.W LR, SP, #0x1C+var_18 
. text:00002BBE 00 92 STR R2, [SP,#0x1C+var_1C] 


. text:00002BCO 4F FO 08 09 MOV.W R9, £8 
. text:00002BCA 8E E8 OA 10 STMIA.W LR, {R1,R3,R12} 


__text:00002BC8 01 21 MOVS R1, +1 

__text :00002BCA 02 22 MOVS R2, 42 

. text:00002BCC 03 23 MOVS R3, +3 

. text:00002BCE CD F8 10 90 STR.W R9, [SP,#0x1C+var C] 
. text:00002BD2 01 FO OA EA BLX | printf 

. text:00002BD6 05 BO ADD SP, SP, 40x14 

_ text:00002BD8 80 BD POP {R7,PC} 


La sortie est presque la méme que dans l'exemple précédent, avec l'exception que 
des instructions Thumb/Thumb-2 sont utilisées a la place. 


ARM64 


GCC (Linaro) 4.9 sans optimisation 


Listing 1.56 : GCC (Linaro) 4.9 sans optimisation 


.LC2: 
.string "a-*d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d\n" 
f3: 
; Réserver plus d'espace dans la pile: 
sub sp, sp, £32 
; sauver FP et LR sur la pile: 
stp x29, x30, [sp,16] 
; définir la pile (FP=SP+16): 
add x29, sp, 16 
adrp X0, .LC2 ; "a=%d; b=%d; c=%d; d-*sd; e=%d; f=%d; g=%d; h=%d\n" 
add x0, x0, :lo12:.LC2 
mov wl, 8 ; 9éme argument 
str wl, [sp] ; Stocker le 9éme argument dans la pile 
mov wl, 1 
mov w2, 2 
mov w3, 3 
mov w4, 4 
mov w5, 5 
mov w6, 6 
mov w7, 7 
bl printf 
sub sp, x29, £16 
; restaurer FP et LR 
ldp x29, x30, [sp,16] 
add sp, sp, 32 


ret 


82 
Les 8 premiers arguments sont passés dans des registres X- ou W-: [Procedure Call 
Standard for the ARM 64-bit Architecture (AArch64), (2013)]”?. Un pointeur de chaîne 
nécessite un registre 64-bit, donc il est passé dans X0. Toutes les autres valeurs ont 
un type int 32-bit, donc elles sont stockées dans la partie 32-bit des registres (W-). Le 
9éme argument (8) est passé par la pile. En effet: il n'est pas possible de passer un 
grand nombre d'arguments par les registres, car le nombre de registres est limité. 


GCC (Linaro) 4.9 avec optimisation génére le méme code. 


1.11.3 MIPS 

3 arguments entier 

GCC 4.4.5 avec optimisation 

La différence principale avec l'exemple «Hello, world! » est que dans ce cas, printf() 
est appelée à la place de puts() et 3 arguments de plus sont passés à travers les 


registres $5...$7 (ou $A0...$A2). C'est pourquoi ces registres sont préfixés avec A-, 
ceci sous-entend qu'ils sont utilisés pour le passage des arguments aux fonctions. 


Listing 1.57 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


$LCO: 
.ascii "a=%d; b=%d; c=%d\000" 


main: 

; prologue de la fonction: 
lui $28,%hi( gnu local gp) 
addiu — $sp,$sp,-32 
addiu  $28,$28,%lo(_ gnu local gp) 
SW $31,28($sp) 

; charger l'adresse de printf(): 
lw $25,%call16 (printf) ($28) 

; charger l'adresse de la chaíne de texte et mettre le ler argument de 

printf(): 

lui $4,%hi($LCO) 


addiu $4,$4,%lo($LCO) 
mettre le 2nd argument de printf(): 
li $5,1 # 0x1 
mettre le 3éme argument de printf(): 
li $6,2 # 0x2 
appeler printf(): 
jalr $25 
mettre le 4éme argument de printf() (slot de délai branchement): 
li $7,3 # 0x3 


épilogue de la fonction: 
lw $31,28($sp) 
mettre la valeur de retour à 0: 
move $2,$0 
retourner 


72 Aussi disponible en http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B _ 
aapcs64.pdf 
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j $31 
addiu 


$sp,$sp,32 ; slot de délai de branchement 


Listing 1.58 : GCC 4.4.5 avec optimisation (IDA) 


.text:00000000 main: 
.text:00000000 


.text:00000000 var 10 - -0x10 
.text:00000000 var 4 = -4 
. text: 00000000 

; prologue de la fonction: 

. text: 00000000 lui 

. text: 00000004 addiu 
. text: 00000008 la 

. text: 0000000C SW 

. text: 00000010 SW 

; charger l'adresse de printf(): 
.text:00000014 lw 


; charger l'adresse de la chaíne de texte et mettre le ler argument de 


printf(): 
.text:00000018 la 
; mettre le 2nd argument de printf(): 
.text:00000020 li 
; mettre le 3éme argument de printf(): 


.text:00000024 li 
; appeler printf(): 
.text:00000028 jalr 


; mettre le 4éme argument de printf(): 


.text:0000002C li 
; épilogue de la fonction: 
.text:00000030 lw 


; mettre la valeur de retour à 0: 


. text: 00000034 move 
; retourner 

.text:00000038 jr 
.text:0000003C addiu 


branchement 


$gp, (__gnu local gp >> 16) 

$sp, -0x20 

$gp, (. gnu local gp € OxFFFF) 

$ra, Ox20+var 4($sp) 

$gp, 0x20+var_10($5p) 

$t9, (printf € OxFFFF) ($gp) 

$a0, $LCO # "a=%d; b=%d ; c=%d" 
$al, 1 

$a2, 2 

$t9 


(slot de délai de branchement) 
$a3, 3 


$ra, Ox20+var 4($sp) 
$v0, $zero 


$ra 
$sp, 0x20 ; slot de délai de 


IDA a agrégé la paire d'instructions LUI et ADDIU en une pseudo instruction LA. C'est 
pourquoi il n'y a pas d'instruction à l'adresse Ox1C: car LA occupe 8 octets. 


GCC 4.4.5 sans optimisation 


GCC sans optimisation est plus verbeux: 


Listing 1.59 : GCC 4.4.5 sans optimisation (résultat en sortie de l'assembleur) 


$LCO: 

.ascii  "a-*d; b=%d; c=%d\000" 
main: 
; prologue de la fonction: 

addiu $sp,$sp,-32 

SW $31,28($sp) 
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Sw $fp,24($sp) 
move $fp,$sp 
lui $28,*5hi( gnu local gp) 


addiu  $28,$28,%lo(_ gnu local gp) 
charger l'adresse de la chaîne de texte: 


lui $2,%hi($LCO) 

addiu $2,$2,%lo($LCO) 
mettre le ler argument de printf(): 
move $4, $2 
; mettre le 2nd argument de printf(): 


li $5,1 

; mettre le 3éme argument de printf(): 
li $6,2 

; mettre le 4éme argument de printf(): 
li $7,3 

; charger l'adresse de printf(): 
lw $2 %call16(printf) ($28) 
nop 


appeler printf(): 
move $25,$2 
jalr $25 
nop 


épilogue de la fonction: 


lw $28,16($fp) 
; mettre la valeur de retour à 0: 
move $2,$0 
move $sp,$fp 
lw $31,28($sp) 
lw $fp,24($sp) 
addiu — $sp,$sp,32 
; retourner 
j $31 
nop 


# 0x1 


# 0x2 


# 0x3 


Listing 1.60 : GCC 4.4.5 sans optimisation (IDA) 


.text:00000000 main: 
.text:00000000 


.text:00000000 var_10 = -0x10 
.text:00000000 var_8 = -8 
.text:00000000 var_4 = -4 
.text:00000000 

; prologue de la fonction: 

. text: 00000000 addiu  $sp, 
.text : 00000004 sw $ra, 
.text : 00000008 sw $fp, 
.text:0000000C move $fp, 
.text:00000010 la $gp, 
.text:00000018 sw $gp, 
; charge l'adresse de la chaine de texte: 

. text: 0000001C la $v0, 
; nettre le ler argument de printf(): 
.text:00000024 move $a0, 


-0x20 

Ox20+var 4($sp) 
Ox20+var 8($sp) 
$sp 

__gnu local gp 
Ox20+var 10($sp) 


aADBDCD # "a-*s 


$v0 
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; mettre le 2nd argument de printf(): 


.text:00000028 li $al, 1 

; mettre le 3éme argument de printf(): 

.text:0000002C li $a2, 2 

; mettre le 4éme argument de printf(): 

.text:00000030 li $a3, 3 

; charger l'adresse de printf(): 

.text:00000034 lw $vO, (printf € OxFFFF) ($gp) 
.text:00000038 or $at, $zero 

; appeler printf(): 

.text:0000003C move $t9, $v0 
.text:00000040 jalr $t9 

.text:00000044 or $at, $zero ; NOP 

; épilogue de la fonction: 

.text:00000048 lw $gp, 0x20+var_10($fp) 
; mettre la valeur de retour à 0: 

.text:0000004C move $v0, $zero 

. text: 00000050 move $sp, $fp 
.text:00000054 lw $ra, Ox20+var 4($sp) 
.text: 00000058 lw $fp, Ox20+var 8($sp) 
.text:0000005C addiu $sp, 0x20 

; retourner 

.text:00000060 jr $ra 

.text:00000064 or $at, $zero ; NOP 


8 arguments entier 


Utilisons encore l'exemple de la section précédente avec 9 arguments: 1.11.1 on 
page 70. 


#include <stdio.h> 


int main() 
{ 
printf("a=%d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%sd\n", 1, 2, 3,2 
G 4, 55 6, TS 8); 
return 0; 


}; 


GCC 4.4.5 avec optimisation 


Seul les 4 premiers arguments sont passés dans les registres $A0 ...$A3, les autres 
sont passés par la pile. 


C'est la convention d'appel O32 (qui est la plus commune dans le monde MIPS). 
D'autres conventions d'appel, ou du code assembleur écrit à la main, peuvent utiliser 
les registres à d'autres fins. 


SW est l'abbréviation de «Store Word » (depuis un registre vers la mémoire). En MIPS, 
il manque une instructions pour stocker une valeur dans la mémoire, donc une paire 
d'instruction doit étre utilisée à la place (LI/SW). 
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Listing 1.61 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


$LCO: 
.ascii  "a-*d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d\012\000" 


main: 

; prologue de la fonction: 
lui $28,%hi( gnu local gp) 
addiu  $sp,$sp,-56 
addiu  $28,$28,%lo(_ gnu local gp) 
SW $31,52($sp) 

; passer le 5éme argument dans la pile: 
li $2,4 # 0x4 
SW $2,16($sp) 

; passer le 6ème argument dans la pile: 
li $2,5 # 0x5 
SW $2,20($sp) 

; passer le 7ème argument dans la pile: 
li $2,6 # 0x6 
SW $2,24($5p) 

; passer le 8éme argument dans la pile: 
li $2,7 # 0x7 
lw $25,%call16 (printf) ($28) 
SW $2,28($sp) 

; passer le ler argument dans $a0: 
lui $4,*shi($LCO) 

; passer le 9éme argument dans la pile: 
li $2,8 # 0x8 
sw $2,32($sp) 


addiu $4,$4,%lo($LCO) 
; passer le 2nd argument dans $al: 


li $5,1 # 0x1 
; passer le 3éme argument dans $a2: 

li $6,2 # 0x2 
; appeler printf(): 

jalr $25 
; passer le 4éme argument dans $a3 (slot de délai de branchement): 

li $7,3 # 0x3 
; épilogue de la fonction: 

lw $31,52($sp) 
; mettre la valeur de retour à 0: 

move $2,$0 
; retourner 

] $31 


addiu  $sp,$sp,56 ; slot de délai de branchement 


Listing 1.62 : GCC 4.4.5 avec optimisation (IDA) 


.text:00000000 main: 
.text:00000000 


.text:00000000 var 28 = -0x28 
.text:00000000 var 24 = -0x24 
.text:00000000 var 20 - -0x20 
.text:00000000 var 1C = -0x1C 
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.text:00000000 var 18 = -0x18 
.text:00000000 var 10 - -0x10 
.text:00000000 var 4 = -4 
.text:00000000 
; prologue de la fonction: 
.text:00000000 lui $gp, 
. text: 00000004 addiu  $sp, 
.text : 00000008 la $gp, 
.text:0000000C sw $ra, 
.text:00000010 sw $gp, 
; passer le 5éme argument dans la pile: 
. text: 00000014 li $v0, 
.text:00000018 sw $v0, 
; passer le 6ème argument dans la pile: 
.text:0000001C li $v0, 
.text:00000020 sw $v0, 
; passer le 7ème argument dans la pile: 
.text:00000024 li $v0, 
.text:00000028 SW $v0, 
; passer le 8éme argument dans la pile: 
.text:0000002C li $v0, 
.text:00000030 lw $t9, 
.text:00000034 sw $v0, 
; préparer le ler argument dans $a0: 
.text:00000038 lui $a0, 
c=%d; d=%d; e=%d; f=%d; g=%"... 
; passer le 9éme argument dans la pile: 
.text:0000003C li $v0, 
.text:00000040 sw $v0, 
; passer le ler argument in $a0: 
.text:00000044 la $a0, 
c=%d; d=%d; e=%d; f=%d; g=%"... 
; passer le 2nd argument dans $al: 
.text:00000048 li $al, 
; passer le 3éme argument dans $a2: 
.text:0000004C li $a2, 
; appeler printf(): 
.text:00000050 jalr $t9 
; passer le 4éme argument dans $a3 (slot de 
.text:00000054 li $a3, 
; épilogue de la fonction: 
.text:00000058 lw $ra, 
; mettre la valeur de retour à Q: 
.text:0000005C move $v0, 
; retourner 
.text:00000060 jr $ra 
. text: 00000064 addiu  $sp, 
branchement 


(  gnu local gp >> 16) 
-0x38 

(__gnu local gp € OxFFFF) 
0x38+var_4($sp) 
0x38+var_10($sp) 

4 

0x38+var_28($sp) 

5 

Ox38+var 24($sp) 


6 
0x38+var_20($sp) 


7 

(printf € OxFFFF) ($gp) 
0x38+var_1C($sp) 

($LCO >> 16) ^£ "a=%d; b=%d; 
8 

0x38+var_18($sp) 


($LCO € OxFFFF) # “a=%d; b=%d; 


délai de branchement): 
3 


Ox38+var_4($sp) 


$zero 


0x38 ; slot de délai de 


GCC 4.4.5 sans optimisation 


GCC sans optimisation est plus verbeux: 
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Listing 1.63 : sans optimisation GCC 4.4.5 (résultat en sortie de l'assembleur) 


$LCO: 

.ascii  "a-*d; b=%d; c=%d; d=%d; e=%d; f=%d; g=%d; h=%d\012\000" 
main: 
; prologue de la fonction: 

addiu  $sp,$sp,-56 


SW $31,52($sp) 

Sw $fp,48($sp) 

move $fp,$sp 

lui $28,%hi( gnu local gp) 
addiu $28,$28,%lo(_ gnu local gp) 
lui $2,%hi($LCO) 


addiu  $2,$2,%lo($LCO) 


; passer le 5éme argument dans la pile: 
li $3,4 # 0x4 
SW $3,16($sp) 
; passer le 6ème argument dans la pile: 
li $3,5 # 0x5 
SW $3,20($sp) 
; passer le 7éme argument dans la pile: 
li $3,6 # 0x6 
SW $3,24($sp) 
; passer le 8éme argument dans la pile: 
li $3,7 # 0x7 
SW $3,28($5p) 
; passer le 9éme argument dans la pile: 
li $3,8 # 0x8 
sw $3,32($sp) 
; passer le ler argument dans $a0: 
move $4,$2 
; passer le 2nd argument dans $al: 
li $5,1 # 0x1 
; passer le 3éme argument dans $a2: 
li $6,2 # 0x2 
; passer le 4éme argument dans $a3: 
li $7,3 # 0x3 
; appeler printf(): 
lw $2 %call16(printf) ($28) 
nop 
move $25,$2 
jalr $25 
nop 
; épilogue de la fonction: 
lw $28,40($fp) 
; mettre la valeur de retour à 0: 
move $2,$0 
move $sp,$fp 
lw $31,52($sp) 
lw $fp,48($sp) 
addiu  $sp,$sp,56 
; retourner 
j $31 


nop 
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Listing 1.64 : sans optimisation GCC 4.4.5 (IDA) 


.text:00000000 main: 

.text:00000000 

.text:00000000 var 28 - -0x28 

.text:00000000 var 24 = -0x24 

.text:00000000 var 20 - -0x20 

.text:00000000 var 1C = -0x1C 

.text:00000000 var_18 = -0x18 

.text:00000000 var 10 - -0x10 

.text:00000000 var 8 = -8 

.text:00000000 var_4 = -4 

.text:00000000 

; prologue de la fonction: 

.text:00000000 addiu 

.text:00000004 sw 

.text:00000008 sw 

.text:0000000C move 

.text:00000010 la 

.text:00000018 SW 

. text: 0000001C la 
c=%d; d=%d; e=%d; f=%d; g=%"... 

; passer le 5éme argument dans la pile: 

.text:00000024 li 

.text:00000028 sw 

; passer le 6ème argument dans la pile: 

.text:0000002C li 

.text:00000030 sw 

; passer le 7éme argument dans la pile: 

.text:00000034 li 

.text:00000038 sw 

; passer le 8éme argument dans la pile: 

.text:0000003C li 

.text:00000040 sw 

; passer le 9éme argument dans la pile: 

.text:00000044 li 

.text:00000048 sw 

; passer le ler argument dans $40: 

.text:0000004C move 

; passer le 2nd argument dans $al: 

.text:00000050 li 

; passer le 3éme argument dans $a2: 

.text:00000054 li 

; passer le 4éme argument dans $a3: 

.text:00000058 li 

; appeler printf(): 

.text:0000005C lw 

. text : 00000060 or 

. text : 00000064 move 

. text: 00000068 jalr 

. text : 0000006C or 

; épilogue de la fonction: 

. text : 00000070 lw 


; mettre la valeur de retour à 0: 


$sp, 
$ra, 
$fp, 
$fp, 
$gp, 
$9p, 
$v0, 


$v1, 
$v1, 


$v1, 
$v1, 


$v1, 
$v1, 


$v1, 
$v1, 


$v1, 
$v1, 


$a0, 
gal, 
$a2, 
$a3, 
$v0, 
$at, 
$t9, 
$t9 

$at, 


$gp, 


-0x38 
Ox38+var_4($sp) 
Ox38+var_8($sp) 
$sp 

. gnu local gp 


0x38+var_10($sp) 
aADBDCDDDEDFDGD  £ "a=%d; b=%d; 
4 

0x38+var_28($sp) 

5 

Ox38+var 24($sp) 

6 

0x38+var_20($sp) 

7 

0x38+var_1C($sp) 

8 

0x38+var_18($sp) 

$v0 

1 

2 

3 

(printf € OxFFFF) ($9p) 
$zero 

$v0 

$zero ; NOP 


0x38+var_10($fp) 


.text:00000074 move $v0, $zero 


.text:00000078 move $sp, $fp 
.text:0000007C lw $ra, 0x38+var_4($sp) 
.text:00000080 lw $fp, 0x38-var 8($sp) 
.text:00000084 addiu $sp, 0x38 

; retourner 

.text:00000088 jr $ra 

.text:0000008C or $at, $zero ; NOP 


1.11.4 Conclusion 
Voici un schéma grossier de l'appel de la fonction: 


Listing 1.65 : x86 


PUSH 3rd argument 

PUSH 2nd argument 

PUSH 1st argument 

CALL fonction 

; modifier le pointeur de pile (si besoin) 


Listing 1.66 : x64 (MSVC) 


MOV RCX, 1st argument 
MOV RDX, 2nd argument 
MOV R8, 3rd argument 
MOV R9, 4th argument 


PUSH 5ème, 6ème argument, etc. (si besoin) 
CALL fonction 
; modifier le pointeur de pile (si besoin) 


Listing 1.67 : x64 (GCC) 


MOV RDI, 1st argument 
MOV RSI, 2nd argument 
MOV RDX, 3rd argument 
MOV RCX, 4th argument 
MOV R8, 5th argument 
MOV R9, 6th argument 


PUSH 7ème, 8ème argument, etc. (si besoin) 
CALL fonction 
; modifier le pointeur de pile (si besoin) 


Listing 1.68 : ARM 


MOV RO, 1st argument 
MOV R1, 2nd argument 
MOV R2, 3rd argument 
MOV R3, 4th argument 
; passer le 5ème, 6ème argument, etc., dans la pile (si besoin) 
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BL fonction 
; modifier le pointeur de pile (si besoin) 


Listing 1.69 : ARM64 


MOV X0, 1st argument 

MOV X1, 2nd argument 

MOV X2, 3rd argument 

MOV X3, 4th argument 

MOV X4, 5th argument 

MOV X5, 6th argument 

MOV X6, 7th argument 

MOV X7, 8th argument 

; passer le 9éme, 10éme argument, etc., dans la pile (si besoin) 
BL fonction 

; modifier le pointeur de pile (si besoin) 


Listing 1.70 : MIPS (O32 calling convention) 


LI $4, 1st argument ; AKA $A0 

LI $5, 2nd argument ; AKA $A1 

LI $6, 3rd argument ; AKA $A2 

LI $7, 4th argument ; AKA $A3 

; passer le 5ème, 6ème argument, etc., dans la pile (si besoin) 
LW temp reg, adresse de la fonction 

JALR temp reg 


1.11.5 À propos 


À propos, cette différence dans le passage des arguments entre x86, x64, fastcall, 
ARM et MIPS est une bonne illustration du fait que le CPU est inconscient de comment 
les arguments sont passés aux fonctions. Il est aussi possible de créer un compilateur 
capable de passer les arguments via une structure spéciale sans utiliser du tout la 
pile. 


Les registres MIPS $A0 ...$A3 sont appelés comme ceci par commodité (c'est dans 
la convention d'appel O32). Les programmeurs peuvent utiliser n'importe quel autre 
registre, (bon, peut-étre à l'exception de $ZERO) pour passer des données ou n'im- 
porte quelle autre convention d'appel. 


Le CPU n'est pas au courant de quoi que ce soit des conventions d'appel. 


Nous pouvons aussi nous rappeler comment les débutants en langage d'assemblage 
passent les arguments aux autres fonctions: généralement par les registres, sans 
ordre explicite, ou méme par des variables globales. Bien súr, cela fonctionne. 


1.12 scanf() 


Maintenant utilisons la fonction scanf(). 
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1.12.1 Exemple simple 


#include <stdio.h> 

int main() 

{ 
int x; 
printf ("Enter X:\n"); 
scanf ("%d", &x); 


printf ("You entered %d...\n", x); 


return 0; 


I| n'est pas astucieux d'utiliser scanf () pour les interactions utilisateurs de nos jours. 
Mais nous pouvons, toutefois, illustrer le passage d'un pointeur sur une variable de 
type int. 


À propos des pointeurs 


Les pointeurs sont l'un des concepts fondamentaux de l'informatique. Souvent, pas- 
ser un gros tableau, structure ou objet comme argument à une autre fonction est 
trop coüteux, tandis que passer leur adresse l'est trés peu. Par exemple, si vous 
voulez afficher une chaîne de texte sur la console, il est plus facile de passer son 
adresse au noyau de l'OS. 


En plus, si la fonction appelée doit modifier quelque chose dans un gros tableau 
ou structure recu comme paramètre et renvoyer le tout, la situation est proche de 
l'absurde. Donc, la chose la plus simple est de passer l'adresse du tableau ou de la 
structure à la fonction appelée, et de la laisser changer ce qui doit l'étre. 


Un pointeur en C/C++—est simplement l'adresse d'un emplacement mémoire quel- 
conque. 


En x86, l'adresse est représentée par un nombre de 32-bit (i.e., il occupe 4 octets), 
tandis qu'en x86-64 c'est un nombre de 64-bit (occupant 8 octets). À propos, c'est la 
cause de l'indignation de certaines personnes concernant le changement vers x86- 
64—tous les pointeurs en architecture x64 ayant besoin de deux fois plus de place, 
incluant la mémoire cache, qui est de la mémoire "coüteuse". 


Il est possible de travailler seulement avec des pointeurs non typés, moyennant 
quelques efforts; e.g. la fonction C standard memcpy(), qui copie un bloc de mé- 
moire d'un endroit à un autre, prend 2 pointeurs de type void* comme arguments, 
puisqu'il est impossible de prévoir le type de données qu'il faudra copier. Les types 
de données ne sont pas importants, seule la taille du bloc compte. 


Les pointeurs sont aussi couramment utilisés lorsqu'une fonction doit renvoyer plus 
d'une valeur (nous reviendrons là-dessus plus tard (3.23 on page 773)). 


La fonction scanf()—en est une telle. 
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Hormis le fait que la fonction doit indiquer combien de valeurs ont été lues avec 
succés, elle doit aussi renvoyer toutes ces valeurs. 


En C/C++ le type du pointeur est seulement nécessaire pour la vérification de type 
lors de la compilation. 


Il n'y a aucune information du tout sur le type des pointeurs à l'intérieur du code 
compilé. 


x86 
MSVC 


Voici ce que l'on obtient aprés avoir compilé avec MSVC 2010: 


CONST SEGMENT 


$5G3831 DB ‘Enter X:', 0aH, 00H 

$5G3832 DB '%d', OOH 

$5G3833 DB ‘You entered %d...', OaH, 00H 
CONST ENDS 

PUBLIC main 

EXTRN  scanf:PROC 

EXTRN _printf:PROC 


; Options de compilation de la fonction: /Odtp 
_ TEXT SEGMENT 


_X$ = -4 : size = 4 
main PROC 

push ebp 

mov ebp, esp 

push ecx 


push OFFSET $SG3831 ; ‘Enter X:' 
call printf 

add esp, 4 

lea eax, DWORD PTR _x$[ebp] 


push eax 

push OFFSET $5G3832 ; '%d' 
call  scanf 

add esp, 8 

mov ecx, DWORD PTR _x$[ebp] 
push ecx 


push OFFSET $SG3833 ; ‘You entered %d...' 
call printf 


add esp, 8 
; retourner 0 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

main ENDP 

. TEXT ENDS 


x est une variable locale. 
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D'aprés le standard C/C++ elle ne doit étre visible que dans cette fonction et dans 
aucune autre portée. Traditionnellement, les variables locales sont stockées sur la 
pile. Il y a probablement d'autres moyens de les allouer, mais en x86, c'est la facon 
de faire. 


Le but de l'instruction suivant le prologue de la fonction, PUSH ECX, n'est pas de 
sauver l'état de ECX (noter l'absence d'un POP ECX à la fin de la fonction). 


En fait, cela alloue 4 octets sur la pile pour stocker la variable x. 


x est accédée à l'aide de la macro _x$ (qui vaut -4) et du registre EBP qui pointe sur 
la structure de pile courante. 


Pendant la durée de l'exécution de la fonction, EBP pointe sur la structure locale de 
pile courante, rendant possible l'accés aux variables locales et aux arguments de la 
fonction via EBP+offset. 


Il est aussi possible d'utiliser ESP dans le méme but, bien que ca ne soit pas très 
commode, car il change fréquemment. La valeur de EBP peut étre percue comme un 
état figé de la valeur de ESP au début de l'exécution de la fonction. 


Voici une structure de pile typique dans un environnement 32-bit: 


EBP-8 variable locale #2, marqué dans IDA comme var 8 
EBP-4 variable locale #1, marqué dans IDA comme var 4 
EBP valeur sauvée de EBP 

EBP+4 adresse de retour 

EBP+8 argument#1, marqué dans IDA comme arg_0 


EBP+0xC argument#2, marqué dans IDA comme arg 4 
EBP+0x10 | argument#3, marqué dans IDA comme arg 8 


La fonction scanf () de notre exemple a deux arguments. 


Le premier est un pointeur sur la chaine contenant %d et le second est l'adresse de 
la variable x. 


Tout d'abord, l'adresse de la variable x est chargée dans le registre EAX par l'instruc- 
tion 
lea eax, DWORD PTR x$[ebp]. 


LEA signifie load effective address (charger l'adresse effective) et est souvent utilisée 
pour composer une adresse (.1.6 on page 1333). 


Nous pouvons dire que dans ce cas, LEA stocke simplement la somme de la valeur 
du registre EBP et de la macro x$ dans le registre EAX. 


C'est la méme chose que lea eax, [ebp-4]. 


Donc, 4 est soustrait de la valeur du registre EBP et le résultat est chargé dans le 
registre EAX. Ensuite, la valeur du registre EAX est poussée sur la pile et scanf () est 
appelée. 


printf() est appelée ensuite avec son premier argument — un pointeur sur la 
chaine: You entered %d...\n. 
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Le second argument est préparé avec: mov ecx, [ebp-4]. L'instruction stocke la 
valeur de la variable x et non son adresse, dans le registre ECX. 


Puis, la valeur de ECX est stockée sur la pile et le dernier appel a printf() est 
effectué. 
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MSVC + OllyDbg 


Essayons cet exemple dans OllyDbg. Chargeons-le et appuyons sur F8 (enjamber) 
jusqu'à ce que nous atteignons notre exécutable au lieu de ntdll.dll. Défiler vers 
le haut jusqu'à ce que main() apparaisse. 


Cliquer sur la premiére instruction (PUSH EBP), appuyer sur F2 (set a breakpoint), 
puis F9 (Run). Le point d'arrét sera déclenché lorsque main() commencera. 


Continuons jusqu'au point où la variable x est calculée: 


SET 
PTR DS: [C&MSUCR18B. printf >] 


a 
ELECO " 4 PTR to ASCII ” 


&MSUCR100. scanf >] : 
> BaE91815 
ES @ jit B(FFFFFFFF) 
CS B(FFFFFFFF) 
BL FFFFFFFF) 
OLFFFFFFFF) 
vEFDDaaatFFF) 
atFFFFFFFF) 


X, DWORD PTR SS: [LOCAL. 1] 


T 00E93010 
PTR DS: [<2MSUCR100. printf >] 


65 6E 74 
aa aa|FF FF FF 
FF FF|61 00 Ø 


Fig. 1.13: OllyDbg : L'adresse de la variable locale est calculée 


Cliquer droit sur EAX dans la fenétre des registres et choisir «Follow in stack ». 


Cette adresse va apparaitre dans la fenétre de la pile. La fléche rouge a été ajoutée, 
pointant la variable dans la pile locale. A ce point, cet espace contient des restes de 
données (0x6E494714). Maintenant. avec l'aide de l'instruction PUSH, l'adresse de cet 
élément de pile va étre stockée sur la méme pile à la position suivante. Appuyons sur 
F8 jusqu'à la fin de l'exécution de scanf ( ). Pendant l'exécution de scanf ( ), entrons, 
par exemple, 123, dans la fenétre de la console: 


Enter X: 
123 
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scanf () a déjà fini de s'exécuter: 


CPU - main thread, module ex1 [Oj x! 
E PUSH EBP A 
pu E 
: 6E445AA0 6E445AA0 
PUSH OFFSET 00E92000 c : GARD 
CALL DWORD PTR DS: [<&MSUCR100.printf>] 66494500 —badioinfo 
ADD ESP,4 ER ta dcr 
LEA EAX, LLOCRL. 11 ; to ASCII T 
PUSH EAX 


PUSH OFFSET GaE9Saac 
CALL DWORD PTR DS:L4&HMSUCRI188. scanf >] 


ADD ESP,8 
MOV ECX, DWORD PTR SS: [LOCAL. 1] 
PUSH ECX 


tFFFFFFFF) 


PUSH OFFSET BBE93018 Fc t OLFFFFFFFF) 


Bt FFFFFFFF) 
7EFDDG@Q( FFF) 
@(FFFFFFFF) 


Fig. 1.14: OllyDbg : scanf() s’est exécutée 


scanf() renvoie 1 dans EAX, ce qui indique qu'elle a lu avec succés une valeur. Si 
nous regardons de nouveau l'élément de la pile correspondant a la variable locale, 
il contient maintenant 0x7B (123). 
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Plus tard, cette valeur est copiée de la pile vers le registre ECX et passée à printf (): 


101 xi 


PUSH EBP 
MOU EBP,ESP 

PUSH ECX 

PUSH OFFSET BaE93008 

CALL DWORD PTR DS: C<&MSUCRIOG. printf >] 
ADD ESP, 4 

LEA EAX, CLOCAL. 11 

PUSH EAX 

8 ac29E209 | PUSH OFFSET BaE9saac 

FF15 B420E301 CALL DWORD PTR DS: (<&MSVCR1@0. scanf >] 
8304 68 ADD ESP, 8 

8B4D FC MOU ECX, DWORD PTR SS: CLOCAL. 1] 

PUSH ECX 


EEEEPEEM 
00000078 


MSUCR1880.  badioinfo 


1.88E9 
1.00E91027 


OLFFFFFFFF) 


51 i 
68 19306909 [PUSH OFFSET B9E93010 prada das 


FF15 2C20E901 CALL DWORD PTR DS:L«&HSUCR188.printf?1 à BLEFFFFFFF) 
ali du BED ESE, S 1 7EFDDBGatFFF) 
a GCFFFFFFFF) 


DUO m mmmmmmmm[z 


) 4» © 
De 


LOT 
© © THO» 0) 
OOw TIO C 


Fig. 1.15: OllyDbg : préparation de la valeur pour la passer à printf() 


GCC 


Compilons ce code avec GCC 4.4.1 sous Linux: 


main proc near 

var 20 - dword ptr -20h 

var 1C - dword ptr -1Ch 

var 4 - dword ptr -4 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 20h 
mov [esp+20h+var_20], offset aEnterX ; "Enter X:" 
call | puts 
mov eax, offset aD ; "%d" 
lea edx, [esp+20h+var_4] 
mov [esp+20h+var_1C], edx 
mov [esp+20h+var_20], eax 
call ___isoc99 scanf 
mov edx, [esp+20h+var_4] 
mov eax, offset aYouEnteredD___ ; "You entered %d...\n" 
mov [esp+20h+var_1C], edx 
mov [esp+20h+var_20], eax 
call _ printf 
mov eax, 0 


leave 
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retn 
main endp 


GCC a remplacé l'appel a printf () avec un appel à puts(). La raison de cela a été 
expliquée dans (1.5.3 on page 29). 


Comme dans l'exemple avec MSVC—les arguments sont placés dans la pile avec 
l'instruction MOV. 


À propos 


Ce simple exemple est la démonstration du fait que le compilateur traduit une liste 
d'expression en bloc-C/C++ en une liste séquentielle d'instructions. Il n'y a rien entre 
les expressions en C/C++, et le résultat en code machine, il n'y a rien entre le dé- 
roulement du flux de contróle d'une expression à la suivante. 

x64 

Le schéma est ici similaire, avec la différence que les registres, plutót que la pile, 
sont utilisés pour le passage des arguments. 


MSVC 


Listing 1.71 : MSVC 2012 x64 


DATA | SEGMENT 


$SG1289 DB ‘Enter X:', OaH, 00H 
$SG1291 DB '%d', OOH 
$SG1292 DB ‘You entered %d...', OaH, QOH 
_DATA ENDS 
_ TEXT SEGMENT 
x$ = 32 
main PROC 
$LN3: 
sub rsp, 56 
lea rcx, OFFSET FLAT:$SG1289 ; ‘Enter X:' 
call printf 
lea rdx, QWORD PTR x$[rsp] 
lea rcx, OFFSET FLAT:$SG1291 ; '%d' 
call scanf 
mov edx, DWORD PTR x$[rsp] 
lea rcx, OFFSET FLAT:$SG1292 ; ‘You entered %d...' 


call printf 


; retourner 0 


xor eax, eax 
add rsp, 56 
ret 0 


main ENDP 
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_ TEXT ENDS 
GCC 
Listing 1.72 : GCC 4.4.6 x64 avec optimisation 

.LC0: 

.string "Enter X:" 
.LC1: 

.string "sd" 
.LC2: 

.string "You entered %d...\n" 
main: 

sub rsp, 24 

mov edi, OFFSET FLAT:.LCO ; "Enter X:" 

call puts 

lea rsi, [rsp+12] 

mov edi, OFFSET FLAT: .LC1 ; "sd" 

xor eax, eax 

call . isoc99 scanf 

mov esi, DWORD PTR [rsp+12] 

mov edi, OFFSET FLAT:.LC2 ; "You entered %d...\n" 

xor eax, eax 

call printf 

; retourner 0 

xor eax, eax 

add rsp, 24 

ret 
ARM 
avec optimisation Keil 6/2013 (Mode Thumb) 
.text:00000042 scanf main 
.text:00000042 
.text:00000042 var 8 - -8 
.text:00000042 
.text:00000042 08 B5 PUSH {R3,LR} 
.text:00000044 A9 AO ADR RO, aEnterX ; "Enter X:\n" 
.text:00000046 06 FO D3 F8 BL _ 2printf 
.text:0000004A 69 46 MOV R1, SP 
.text:0000004C AA A0 ADR RO, aD ; "sd" 
.text:0000004E 06 FO CD F8 BL . Oscanf 
.text:00000052 00 99 LDR R1, [SP,#8+var_ 8] 
. text: 00000054 A9 AO ADR RO, aYouEnteredD___ ; "You entered 

%d...\n" 

.text:00000056 06 FO CB F8 BL __2printf 
.text:0000005A 00 20 MOVS RO, +0 


© © U1 SU NJ FH 
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.text:0000005C 08 BD POP {R3,PC} 


Afin que scanf () puisse lire l'item, elle a besoin d'un paramétre—un pointeur sur un 
int. Le type int est 32-bit, donc nous avons besoin de 4 octets pour le stocker quelque 
part en mémoire, et il tient exactement dans un registre 32-bit. De l'espace pour la 
variable locale x est allouée sur la pile et IDA l'a nommée var 8. Il n'est toutefois 
pas nécessaire de définir cette macro, puisque le SP (pointeur de pile) pointe déjà 
sur cet espace et peut étre utilisé directement. 


Donc, la valeur de SP est copiée dans la registre R1 et, avec la chaîne de format, 
passée à scanf(). 


Les instructions PUSH/POP se comportent différemment en ARM et en x86 (c'est l'in- 
verse) Il y a des sysnonymes aux instructions STM/STMDB/LDM/LDMIA. Et l'instruction 
PUSH écrit d'abord une valeur sur la pile, et ensuite soustrait 4 de SP. De ce fait, aprés 
PUSH, SP pointe sur de l'espace inutilisé sur la pile. Il est utilisé par scanf (), et aprés 
par printf(). 


LDMIA signifie Load Multiple Registers Increment address After each transfer (charge 
plusieurs registres incrémente l'adresse aprés chaque transfert). STMDB signifie Store 
Multiple Registers Decrement address Before each transfer (socke plusieurs registres 
décrémente l'adresse avant chaque transfert). 


Plus tard, avec l'aide de l'instruction LDR, cette valeur est copiée depuis la pile vers 
le registre R1 afin de la passer à printf(). 


ARM64 
Listing 1.73 : GCC 4.9.1 ARM64 sans optimisation 
.LC0: 
.string "Enter X:" 
.LC1: 
.string "sd" 
.LC2: 


.string "You entered %d...\n" 
scanf main: 
; soustraire 32 de SP, puis sauver FP et LR dans la structure de pile: 
stp x29, x30, [sp, -32]! 
; utiliser la partie de pile (FP=SP) 
add x29, sp, 0 
charger le pointeur sur la chaíne "Enter X:": 
adrp x0, .LCO 
add x0, x0, :1012:.LCO0 
X0=pointeur sur la chaîne "Enter X:" 
; l'afficher: 
bl puts 
charger le pointeur sur la chaine "%d": 
adrp x0, .LC1 
add x0, x0, :lo12:.LC1 
; trouver de l'espace dans la structure de pile pour la variable "x" 
(X1=FP+28) : 
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add x1, x29, 28 

; Xl=adresse de la variable "x" 

; passer l'adresse de scanf() et l'appeler: 
bl . isoc99 scanf 


charger la valeur 32-bit de la variable dans la partie de pile: 
ldr w1, [x29,28] 


; W1=x 
charger le pointeur sur la chaîne "You entered %d...\n" 
printf() va prendre la chaîne de texte de X0 et de la variable "x" de X1 


(ou W1) 

adrp x0, .LC2 
add x0, x0, :lo12:.LC2 
bl printf 

; retourner 0 
mov w0, 0 

; restaurer FP et LR, puis ajouter 32 à SP: 
ldp x29, x30, [sp], 32 
ret 


Il y a 32 octets alloués pour la structure de pile, ce qui est plus que nécessaire. Peut- 
étre dans un soucis d'alignement de mémoire? La partie la plus intéressante est de 
trouver de l'espace pour la variable x dans la structure de pile (ligne 22). Pourquoi 
28? Pour une certaine raison, le compilateur a décidé de stocker cette variable à la 
fin de la structure de pile locale au lieu du début. L'adresse est passée à scanf(), 
qui stocke l'entrée de l'utilisateur en mémoire à cette adresse. Il s'agit d'une valeur 
sur 32-bit de type int. La valeur est prise à la ligne 27 puis passée a printf(). 


MIPS 


Une place est allouée sur la pile locale pour la variable z, et elle doit étre appelée 
par $sp 4- 24. 


Son adresse est passée à scanf(), et la valeur entrée par l'utilisateur est chargée 
en utilisant l'instruction LW («Load Word »), puis passée à printf(). 


Listing 1.74 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 


$LCO: 
ascii "Enter X:\000" 


$LC1: 
.ascii "%d\000" 
$LC2: 
.ascii "You entered %d...\012\000" 
main: 
; prologue de la fonction: 
lui $28,%hi( gnu local gp) 
addiu $sp,$sp,-40 
addiu  $28,$28,%lo(_ gnu local gp) 
SW $31,36($sp) 
; appel de puts(): 
lw $25,%call16(puts) ($28) 
lui $4,%hi($LC0) 


jalr $25 
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addiu $4,$4,%lo($LCO) ; slot de délai de branchement 
; appel de scanf(): 


lw $28,16($sp) 
lui $4,%hi($LC1) 
lw $25, %call16(_ isoc99 scanf) ($28) 


définir le 2nd argument de scanf(), $al=$sp+24: 
addiu  $5,$sp,24 
jalr $25 
addiu $4,$4,%lo($LC1) ; slot de délai de branchement 


; appel de printf(): 

lw $28,16($sp) 
définir le 2nd argument de printf(), 
; charger un mot à l'adresse $sp+24: 


lw $5,24($sp) 

lw $25 ,%call16 (printf) ($28) 
lui $4,*shi($LC2) 

jalr $25 


addiu $4,$4,%lo($LC2) ; slot de délai de branchement 


épilogue de la fonction: 


lw $31,36($sp) 
; mettre la valeur de retour à 0: 
move $2,$0 
; retourner: 
j $31 
addiu  $sp,$sp,40 ; slot de délai de branchement 


IDA affiche la disposition de la pile comme suit: 


Listing 1.75 : GCC 4.4.5 avec optimisation (IDA) 


.text:00000000 main: 
.text:00000000 


.text:00000000 var 18 = -0x18 

.text:00000000 var 10 = -0x10 

.text:00000000 var 4 = -4 

. text: 00000000 

; prologue de la fonction: 

. text: 00000000 lui $gp, ( gnu local gp >> 16) 

.text:00000004 addiu $sp, -0x28 

.text:00000008 la $gp, ( gnu local gp € OxFFFF) 

.text:0000000C SW $ra, 0x28+var_4($sp) 

.text:00000010 sw $gp, Ox28+var 18($sp) 

; appel de puts(): 

.text:00000014 lw $t9, (puts € OXxFFFF) ($gp) 

.text:00000018 lui $a0, ($LCO >> 16) # "Enter X:" 

.text:0000001C jalr $t9 

.text:00000020 la $a0, ($LCO & OXFFFF) # "Enter X:" ; slot de 
délai de branchement 

; appel de scanf(): 

.text:00000024 lw $gp, 0x28+var_18($5p) 

.text:00000028 lui $a0, ($LC1 >> 16) # "5d" 


.text:0000002C lw $t9, ( isoc99 scanf € OXxFFFF) ($gp) 
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; définir le 2nd argument de scanf(), $al=$sp+24: 


.text:00000030 addiu $al, $sp, 0x28+var_10 
.text:00000034 jalr $t9 ; slot de délai de branchement 
.text:00000038 la $a0, ($LC1 € OxFFFF) 4 "5d" 

; appel de printf(): 

.text:0000003C lw $gp, Ox28+var_18($sp) 


; définir le 2nd argument de printf(), 
; charger un mot à l'adresse $sp+24: 


.text:00000040 lw $al, Ox28+var 10($sp) 

. text: 00000044 lw $t9, (printf € OxFFFF) ($gp) 

. text: 00000048 lui $20, ($LC2 >> 16) # "You entered %d...\n" 

. text: 0000004C jalr $t9 

.text:00000050 la $a0, ($LC2 € OXFFFF) # "You entered %d...\n" 


; slot de délai de branchement 
; épilogue de la fonction: 


.text:00000054 lw $ra, Ox28+var 4($sp) 

; mettre la valeur de retour à 0: 

.text:00000058 move $v0, $zero 

; retourner: 

.text:0000005C jr $ra 

. text: 00000060 addiu  $sp, 0x28 ; slot de délai de branchement 


1.12.2 Erreur courante 


C'est une erreur trés courante (et/ou une typo) de passer la valeur de x au lieu d'un 
pointeur sur x : 


#include <stdio.h> 
int main() 
{ 
int x; 
printf ("Enter X:\n"); 
scanf ("%d", x); // BUG 
printf ("You entered %d...\n", x); 


return 0; 


}; 


Donc que se passe-t-il ici? x n’est pas initialisée et contient des données aléatoires 
de la pile locale. Lorsque scanf() est appelée, elle prend la chaîne de l'utilisateur, la 
convertit en nombre et essaye de l'écrire dans x, la considérant comme une adresse 
en mémoire. Mais il s'agit de bruit aléatoire, donc scanf () va essayer d'écrire à une 
adresse aléatoire. Trés probablement, le processus va planter. 


Assez intéressant, certaines bibliothéques CRT compilées en debug, mettent un signe 
distinctif lors de l'allocation de la mémoire, comme OxCCCCCCCC ou OxOBADFOOD 
etc. Dans ce cas, x peut contenir OXCCCCCCCC, et scanf() va essayer d'écrire à 
l'adresse OXCCCCCCCC. Et si vous remarquez que quelque chose dans votre pro- 
cessus essaye d'écrire à l'adresse OXCCCCCCCC, vous saurez qu'une variable non 
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initialisée (ou un pointeur) a été utilisée sans initialisation préalable. C'est mieux 
que si la mémoire nouvellement allouée est juste mise à zéro. 


1.12.3 Variables globales 


Que se passe-t-il si la variable x de l'exemple précédent n'est pas locale mais glo- 
bale? Alors, elle sera accessible depuis n'importe quel point, plus seulement de- 
puis le corps de la fonction. Les variables globales sont considérées comme un anti- 
pattern, mais dans un but d'expérience, nous pouvons le faire. 


#include <stdio.h> 


// maintenant x est une variable globale 


int x; 
int main() 
{ 
printf ("Enter X:\n"); 
scanf ("%d", &x); 
printf ("You entered %d...\n", x); 
return 0; 
}; 
MSVC: x86 
_DATA SEGMENT 
COMM  _x:DWORD 
$SG2456 DB ‘Enter X:', OaH, 00H 
$SG2457 DB 'sd', OOH 
$SG2458 DB ‘You entered %d...', OaH, 00H 
_DATA ENDS 
PUBLIC main 
EXTRN _scanf:PROC 
EXTRN _printf:PROC 


; Function compile flags: /Odtp 
_ TEXT SEGMENT 


main PROC 
push ebp 
mov ebp, esp 


push OFFSET $SG2456 
call printf 

add esp, 4 

push OFFSET x 

push OFFSET $5G2457 


call  scanf 

add esp, 8 

mov eax, DWORD PTR x 
push eax 


push OFFSET $SG2458 
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call printf 


add esp, 8 
xor eax, eax 
pop ebp 
ret 0 

_main ENDP 

_ TEXT ENDS 


Dans ce cas, la variable x est définie dans la section DATA et il n'y a pas de mémoire 
allouée sur la pile locale. Elle est accédée directement, pas par la pile. Les variables 
globales non initialisées ne prennent pas de place dans le fichier exécutable (en effet, 
pourquoi aurait-on besoin d'allouer de l'espace pour des variables initialement mises 
à zéro ?), mais lorsque quelqu'un accède à leur adresse, l'OS va y allouer un bloc de 
zéros^?. 


Maintenant, assignons explicitement une valeur à la variable: 


int x=10; // valeur par défaut 


Nous obtenons: 


DATA | SEGMENT 
(X DD OaH 


Ici nous voyons une valeur 0xA de type DWORD (DD signifie DWORD = 32 bit) pour 
cette variable. 


Si vous ouvrez le .exe compilé dans IDA, vous pouvez voir la variable x placée au 
début du segment DATA, et après elle vous pouvez voir la chaîne de texte. 


Si vous ouvrez le .exe compilé de l'exemple précédent dans IDA, ou la valeur de x 
n'était pas mise, vous verrez quelque chose comme ca: 


Listing 1.76 : IDA 


.data:0040FA80 x dd ? ; DATA XREF: main+10 
.data:0040FA80 ; main-22 

.data:0040FA84 dword_40FA84 dd ? ; DATA XREF: memset+1E 
.data:0040FA84 ; unknown libname 1+28 
.data:0040FA88 dword_40FA88 dd ? ; DATA XREF: sbh find block+5 
.data:0040FA88 ; sbh free block+2BC 
.data:0040FA8C ; LPVOID lpMem 

.data:0040FA8C lpMem dd ? ; DATA XREF: sbh find block+B 
.data:0040FA8C : sbh free block+2CA 
.data:0040FA90 dword 40FA90 dd ? ; DATA XREF: V6 HeapAlloc+13 
.data:0040FA90 ; calloc impl+72 
.data:0040FA94 dword 40FA94 dd ? ; DATA XREF: sbh free block+2FE 


x est marquée avec ? avec le reste des variables qui ne doivent pas être initialisées. 
Ceci implique qu'aprés avoir chargé le .exe en mémoire, de l'espace pour toutes 


73 C'est comme ça que se comportent les VM 
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ces variables doit étre alloué et rempli avec des zéros [ISO/IEC 9899:TC3 (C C99 
standard), (2007)6.7.8p10]. Mais dans le fichier .exe, ces variables non initialisées 
n'occupent rien du tout. C'est pratique pour les gros tableaux, par exemple. 
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MSVC: x86 + OllyDbg 


Les choses sont encore plus simple ici: 


main thread, module ex2 
Registers (FPU) 


60860061 
CX 6E445AA0 NSUCR1GG.6E445AAG 
xX 6E494508 MSUCRiGG.__badioinfo 


C PTR to ASCII "zd" 
4 


GC51821 
BtFFFFFFFF) 
BC FFFFFFFF) 
@(FFFFFFFF) 
OLFFFFFFFF) 

Sa FSG jit 7EFDDGGG( FFF) 
zoan @ GS 0028 32bit G(FFFFFFFF) 


Imm=8 
ESP=0044F74C, PTR to ASCII "Zd" 0 A LastErr 
EFL 99988296 


TEFDEGGG 


Fig. 1.16: OllyDbg : aprés l'exécution de scanf() 


La variable se trouve dans le segment de données. Aprés que l'instruction PUSH 
(pousser l'adresse de z) ait été exécutée, l'adresse apparait dans la fenétre de la pile. 
Cliquer droit sur cette ligne et choisir «Follow in dump ». La variable va apparaitre 
dans la fenétre de la mémoire sur la gauche. Aprés que nous ayons entré 123 dans 
la console, 0x7B apparait dans la fenétre de la mémoire (voir les régions surlignées 
dans la copie d'écran). 


Mais pourquoi est-ce que le premier octet est 7B? Logiquement, II devrait y avoir 
00 00 00 7B ici. La cause de ceci est référé comme endianness, et x86 utilise /ittle- 
endian. Cela implique que l'octet le plus faible poids est écrit en premier, et le plus 
fort en dernier. Voir à ce propos: 2.2 on page 586. Revenons à l'exemple, la valeur 
32-bit est chargée depuis son adresse mémoire dans EAX et passée à printf(). 


L'adresse mémoire de x est 0x00C53394. 
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Dans OllyDbg nous pouvons examiner l'espace mémoire du processus (Alt-M) et 
nous pouvons voir que cette adresse se trouve dans le segment PE .data de notre 
programme: 


Address | Size Owner Section | Contains Type| Access | Initial] Mapped as aj 
66078600) 66067000 C:\Windows\System32% locale.nl¢ 
96199866) 20905006 Heap 
96269000) 60007006 
0044C000| 00001000 
B0440000| 00003000 Stack of main thread 
86590000) 00067006 
90750000) aaaacaaa Default heap 
aacsaaana| 20081006 PE header 
aacciaaoa| 00001000 «text 
BO0CS2000| 60961006 .rdata 
B0C53000 09691000 «data 
B0C54000| 00001000 .reloc Re locat ions 

£E3E0000| 66001606) MSUCR100 PE header 

£6E3E1000| aaap2aaa| MSUCR100 «Text Code, imports, exports 
£E493000| 66066006) MSUCR108 «data Data 

6E499000| 00001000 | MSUCR100 .rsrc Resources 

£E49A000| aaaacaaa| HSUCRI GO .reloo | Relocations 

75500090 | 64061906) Mod_755D PE header 

75501000 | 60883006 
75504606 | 00001000 
75505666 | 60863006 
755E0000| 86001900) Mod_755E PE header 
755E1000| 00040000 
7562E900| aaaacana 
75633000 | 00009900A 
75640000 | 090091900 | Mod 7564 PE header 
75641000| 00033000 
75679000 | 00002606 
7567B000| 00004000 
76FS50900| 00010900 | kerne 132 PE header 

76F60000| aaaDaaaa! kerne 132 Code, imports, exports 
77930000) 66019000) kerne 132 Data 

77646006) 66010000) kerne 132 Resources 

77656006) 66068000) kerne 132 Relocat ions 

77810006! 64001906) KERNELBASE PE header 

77811600) 66040006) KERNELBASE Code, imports, exports 
77851600) 6902006) KERNELBASE Data 

77853666 | 66061606) KERNELBASE Resources 

77254000 | aaaa2aona| KERNELBASE Relocations 

77B20000| 66061606) Mod_77B2 PE header 

77B21000| 00102000 
77C23000| 6082F 006 
77C52000| 6008606 
77C5E000| 60868096 
77000900 | 60961606 PE header 
77016666) 48806696 Code, exports 
770F 980) 6900190009 RT Code 
7 aa aa a 


= 


= 
m 


= 
m 


= 
m 


= 
m 


= 
m 


= 
m 


mm 


= 


120 20 20 20 Z0 Z0 20 20 20 20 20 22 20 20 20 20 22 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2022 


Data 


Fig. 1.17: OllyDbg : espace mémoire du processus 


GCC: x86 


Le schéma sous Linux est presque le méme, avec la différence que les variables 
non initialisées se trouvent dans le segment bss. Dans un fichier ELF/^ ce segment 
possede les attributs suivants: 


Segment type: Uninitialized 
Segment permissions: Read/Write 


D 
D 


Si toutefois vous initialisez la variable avec une valeur quelconque, e.g. 10, elle sera 
placée dans le segment data, qui posséde les attributs suivants: 


Segment type: Pure data 
Segment permissions: Read/Write 


D 
D 


7^ Executable and Linkable Format: Format de fichier exécutable couramment utilisé sur les systémes 
*NIX, Linux inclus 
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MSVC: x64 


Listing 1.77 : MSVC 2012 x64 


_DATA | SEGMENT 
COMM X:DWORD 


$SG2924 DB ‘Enter X:', OaH, 00H 
$SG2925 DB '%d', OOH 
$SG2926 DB 'You entered %d...', OaH, 00H 
_DATA ENDS 
_ TEXT SEGMENT 
main PROC 
$LN3: 
sub rsp, 40 
lea rcx, OFFSET FLAT:$SG2924 ; ‘Enter X:' 
call printf 
lea rdx, OFFSET FLAT:x 
lea rcx, OFFSET FLAT:$SG2925 ; '%d' 
call scanf 
mov edx, DWORD PTR x 
lea rcx, OFFSET FLAT:$SG2926 ; ‘You entered %d...' 


call printf 


; retourner 0 


xor eax, eax 
add rsp, 40 
ret 0 

main ENDP 

_ TEXT ENDS 


Le code est presque le méme qu'en x86. Notez toutefois que l'adresse de la variable 
x est passée à scanf() en utilisant une instruction LEA, tandis que la valeur de 
la variable est passée au second printf() en utilisant une instruction MOV. DWORD 
PTR—fait partie du langage d'assemblage (aucune relation avec le code machine), 
indique que la taille de la variable est 32-bit et que l'instruction MOV doit étre encodée 
en conséquence. 


ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.78 : IDA 


.text:00000000 ; Segment type: Pure code 


.text:00000000 AREA .text, CODE 

.text:00000000 main 

.text:00000000 PUSH {R4,LR} 

. text: 00000002 ADR RO, aEnterX ; "Enter X:\n" 
. text: 00000004 BL . 2printf 

. text : 00000008 LDR R1, =x 


.text:0000000A ADR RO, aD ; "ed" 
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. text: 0000000C BL _ Oscanf 

.text:00000010 LDR RO, =x 

.text:00000012 LDR R1, [RO] 

.text:00000014 ADR RO, aYouEnteredD . ; "You entered %d...\n" 

.text:00000016 BL . 2printf 

.text:0000001A MOVS RO, 40 

.text:0000001C POP (R4, PC} 

.text:00000020 aEnterX DCB "Enter X:",0xA,0 ; DATA XREF: main+2 

.text:0000002A DCB 0 

.text:0000002B DCB 0 

.text:0000002C off 2C DCD x ; DATA XREF: main+8 

.text:0000002C ; main+10 

.text:00000030 aD DCB "%d",0 ; DATA XREF: main+A 

.text:00000033 DCB 0 

.text:00000034 aYouEnteredD DCB "You entered %d...",0xA,0 ; DATA XREF: 
main+14 

.text:00000047 DCB 0 

.text:00000047 ; .text ends 

.text:00000047 

.data:00000048 ; Segment type: Pure data 

.data:00000048 AREA .data, DATA 

.data:00000048 ; ORG 0x48 

.data:00000048 EXPORT x 

.data:00000048 x DCD OxA ; DATA XREF: main+8 

.data:00000048 ; main+10 

.data:00000048 ; .data ends 


Donc, la variable x est maintenant globale, et pour cette raison, elle se trouve dans 
un autre segment, appelé le segment de données (.data). On pourrait demander 
pour quoi les chaines de textes sont dans le segment de code (.text) et x là. C'est 
parque c'est une variable et que par définition sa valeur peut changer. En outre, elle 
peut méme changer souvent. Alors que les chaînes de texte ont un type constant, 
elles ne changent pas, donc elles sont dans le segment .text. 


Le segment de code peut parfois se trouver dans la ROM”? d'un circuit (gardez à 
l'esprit que nous avons maintenant affaire avec de l'électronique embarquée, et 
que la pénurie de mémoire y est courante), et les variables —en RAM. 


Il n'est pas trés économique de stocker des constantes en RAM quand vous avez de 
la ROM. 


En outre, les variables en RAM doivent étre initialisées, car aprés le démarrage, la 
RAM, évidemment, contient des données aléatoires. 


En avancant, nous voyons un pointeur sur la variable x (off 2C) dans le segment de 
code, et que toutes les opérations avec cette variable s'effectuent via ce pointeur. 


Car la variable x peut se trouver loin de ce morceau de code, donc son adresse doit 
étre sauvée proche du code. 


75Mémoire morte 


OOAONAUBWNE 
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L’instruction LDR en mode Thumb ne peut adresser des variables que dans un inter- 
valle de 1020 octets de son emplacement. 


et en mode ARM —l’intervalle des variables est de +4095 octets. 


Et donc l'adresse de la variable x doit se trouver quelque part de trés proche, car 
il n'y a pas de garantie que l'éditeur de liens pourra stocker la variable proche du 
code, elle peut méme se trouver sur un module de mémoire externe. 


Encore une chose: si une variable est déclarée comme const, le compilateur Keil va 
l'allouer dans le segment .constdata. 


Peut-être qu'après, l'éditeur de liens mettra ce segment en ROM aussi, à côté du 
segment de code. 


ARM64 
Listing 1.79 : GCC 4.9.1 ARM64 sans optimisation 
. comm x,4,4 
.LC0: 
.string "Enter X:" 
.LC1: 
.string "sd" 
.LC2: 
.string "You entered %d...\n" 
f5: 
; sauver FP et LR dans la structure de pile locale: 
stp x29, x30, [sp, -16]! 
; définir la pile locale (FP=SP) 
add x29, sp, 0 


charger le pointeur sur la chaíne "Enter X:": 
adrp x0, .LCO 
add x0, x0, :1012:.LCO0 
bl puts 
charger le pointeur sur la chaíne "%d": 
adrp x0, .LC1 


add x0, x0, :1012:.LC1 
; générer l'adresse de la variable globale x: 
adrp xl, x 
add x1, x1, :lo12:x 
bl . isoc99 scanf 
; générer à nouveau l'adresse de la variable globale x: 
adrp x0, x 
add x0, x0, :lo12:x 


charger la valeur de la mémoire à cette adresse: 
ldr wl, [x0] 

charger le pointeur sur la chaîne "You entered %d...\n": 
adrp x0, .LC2 


add x0, x0, :lo12:.LC2 
bl printf 

; retourner 0 
mov w0, 0 


restaurer FP et LR: 
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36 ldp x29, x30, [sp], 16 
37 ret 


Dans ce car la variable z est déclarée comme étant globale et son adresse est cal- 
culée en utilisant la paire d'instructions ADRP/ADD (lignes 21 et 25). 
MIPS 


Variable globale non initialisée 


Donc maintenant, la variable x est globale. Compilons en un exécutable plutót qu'un 
fichier objet et chargeons-le dans IDA. IDA affiche la variable x dans la section ELF 
.Sbss (vous vous rappelez du «Pointeur Global » ? 1.5.4 on page 34), puisque cette 
variable n'est pas initialisée au début. 


Listing 1.80 : GCC 4.4.5 avec optimisation (IDA) 


.text:004006C0 main: 

.text:004006C0 

.text:004006C0 var 10 = -0x10 

.text:004006C0 var 4 = -4 

. text : 004006C0 

; prologue de la fonction: 

. text: 004006C0 lui $9p, 0x42 

. text: 004006C4 addiu  $sp, -0x20 

.text:004006C8 li $gp, 0x418940 

.text:004006CC SW $ra, Ox20+var 4($sp) 

.text : 004006D0 sw $gp, Ox20+var 10($sp) 

; appel de puts(): 

.text:004006D4 la $t9, puts 

.text:004006D8 lui $a0, 0x40 

.text:004006DC jalr $t9 ; puts 

.text : 004006E0 la $a0, aEnterX # "Enter X:" ; slot de délai 
de branchement 

; appel de scanf(): 

. text: 004006E4 lw $gp, Ox20+var 10($sp) 

.text:004006E8 lui $a0, 0x40 

.text:004006EC la $t9, — isoc99 scanf 

; préparer l'adresse de x: 

.text:004006F0 la $al, x 

.text:004006F4 jalr $t9 ; isoc99 scanf 

.text:004006F8 la $a0, aD # "sd" ; slot de délai de 
branchement 

; appel de printf(): 

.text:004006FC lw $gp, Ox20+var 10($sp) 

.text:00400700 lui $a0, 0x40 

; prendre l'adresse de x: 

.text:00400704 la $v0O, x 

.text:00400708 la $t9, printf 

; charger la valeur de la variable "x" et la passer à printf() dans $al: 

.text:0040070C lw $al, (x - 0x41099C) ($v0) 

. text: 00400710 jalr $t9 ; printf 


WO U1 SUN) H 
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.text:00400714 la $a0, aYouEnteredD . + "You entered %d...\n" 
; slot de délai de branchement 
; épilogue de la fonction: 


.text:00400718 lw $ra, Ox20+var 4($sp) 

.text:0040071C move $v0, $zero 

.text:00400720 jr $ra 

.text:00400724 addiu $sp, 0x20 ; slot de délai de branchement 


.sbss:0041099C + Type de segment: Non initialisé 


.Sbss:0041099C .Sbss 
.sbss:0041099C .globl x 
.Sbss:0041099C x: .Space 4 


.Sbss:0041099C 


IDA réduit le volume des informations, donc nous allons générer un listing avec obj- 
dump et le commenter: 


Listing 1.81 : GCC 4.4.5 avec optimisation (objdump) 


004006c0 «main»: 

; prologue de la fonction: 
4006c0: 3c1c0042 lui gp,0x42 
4006c4: 27bdffe0 addiu sp,sp, -32 
4006c8: 279c8940 addiu gp,gp,-30400 


4006cc: afbf001c sw ra,28(sp) 
4006d0: afbc0010 sw gp,16(sp) 

; appel de puts(): 
4006d4: 8f998034 lw t9,-32716(9p) 
4006d8: 3c040040 lui a0,0x40 


4006dc: 0320f809 jalr t9 
4006e0: 248408f0 addiu a0,a0,2288 ; slot de délai de branchement 
; appel de scanf(): 


4006e4: 8fbc0010 lw gp,16(sp) 

4006e8: 3c040040 lui a0,0x40 

4006ec: 8f998038 lw t9, -32712(gp) 
; préparer l'adresse de x: 

4006f0: 8f858044 lw al,-32700(gp) 


4006f4: 0320f809 jalr t9 
4006f8: 248408fc addiu a0,a0,2300 ; slot de délai de branchement 
; appel de printf(): 


4006fc: 8fbc0010 lw gp,16(sp) 
400700: 3c040040 lui a0 ,0x40 
; prendre l'adresse de x: 
400704: 8f828044 lw v0, -32700(gp) 
400708: 8f99803c lw t9,-32708(9p) 
; charger la valeur de la variable "x" et la passer à printf() dans $al: 
40070c: 8c450000 lw al,0(v0) 


400710: 0320f809 jalr t9 

400714: 24840900 addiu a0,a0,2304 ; slot de délai de branchement 
épilogue de la fonction: 

400718: 8fbf001c lw ra,28(sp) 

40071c: 00001021 move vO,zero 
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400720: 03e00008 jr ra 
400724: 27bd0020 addiu sp,sp,32 ; slot de délai de branchement 
groupe de NOPs servant a aligner la prochaine fonction sur un bloc de 


16-octet: 
400728: 00200825 move at,at 
40072c: 00200825 move at,at 


Nous voyons maintenant que l'adresse de la variable x est lue depuis un buffer de 
64KiB en utilisant GP et en lui ajoutant un offset négatif (ligne 18). Plus que ca, les 
adresses des trois fonctions externes qui sont utilisées dans notre exemple (puts (), 
scanf(), printf ()), sont aussi lues depuis le buffer de données globale en utilisant 
GP (lignes 9, 16 et 26). GP pointe sur le milieu du buffer, et de tels offsets suggèrent 
que les adresses des trois fonctions, et aussi l'adresse de la variable z, sont toutes 
stockées quelque part au début du buffer. Cela fait du sens, car notre exemple est 
minuscule. 


Une autre chose qui mérite d'étre mentionnée est que la fonction se termine avec 
deux NOPs (MOVE $AT,$AT — une instruction sans effet), afin d'aligner le début de 
la fonction suivante sur un bloc de 16-octet. 


Variable globale initialisée 


Modifions notre exemple en affectant une valeur par défaut à la variable z : 


int x=10; // valeur par défaut 


Maintenant IDA montre que la variable x se trouve dans la section .data: 


Listing 1.82 : GCC 4.4.5 avec optimisation (IDA) 


.text:004006A0 main: 
.text:004006A0 
.text:004006A0 var 10 - 
.text:004006A0 var 8 = -8 


.text:004006A0 var 4 -4 

.text:004006A0 

.text:004006A0 lui $gp, 0x42 
.text:004006A4 addiu $sp, -0x20 
.text:004006A8 li $gp, 0x418930 
.text:004006AC SW $ra, 0x20+var_4($sp) 
.text:004006B0 SW $s0, Ox20+var_8($sp) 
. text :004006B4 SW $gp, 0x20+var_10($sp) 
.text:004006B8 la $t9, puts 
.text:004006BC lui $a0, 0x40 
.text:004006C0 jalr $t9 ; puts 
.text:004006C4 la $a0, aEnterX # "Enter X:" 
. text: 004006C8 lw $gp, Ox20+var_10($sp) 
; préparer la partie haute de l'adresse de x: 

. text: 004006CC lui $s0, 0x41 
.text:004006D0 la $t9, | isoc99 scanf 
.text:004006D4 lui $a0, 0x40 


; et ajouter la partie basse de l'adresse de x: 
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.text:004006D8 addiu $al, $50, (x - 0x410000) 
; maintenant l'adresse de x est dans fal. 

. text: 004006DC jalr $t9 ; isoc99 scanf 
.text:004006E0 la $a0, aD # "sd" 
. text: 004006E4 lw $gp, Ox20+var 10($sp) 

; prendre un mot dans la mémoire: 

.text:004006E8 lw $al, x 

; la valeur de x est maintenant dans fal. 
.text:004006EC la $t9, printf 
.text:004006F0 lui $a0, 0x40 

.text:004006F4 jalr $t9 ; printf 
.text:004006F8 la $a0, aYouEnteredD £ "You entered %d...\n" 
.text:004006FC lw $ra, Ox20+var 4($sp) 
.text :00400700 move $v0, $zero 
.text:00400704 lw $s0, Ox20+var_8($sp) 

. text: 00400708 jr $ra 

.text:0040070C addiu $sp, 0x20 

.data:00410920 .globl x 

.data:00410920 x: .word OxA 


Pourquoi pas .sdata? Peut-étre que cela dépend d'une option de GCC? 


Néanmoins, maintenant x est dans .data, qui une zone mémoire générale, et nous 
pouvons regarder comment y travailler avec des variables. 


L'adresse de la variable doit étre formée en utilisant une paire d'instructions. 


Dans notre cas, ce sont LUI («Load Upper Immediate ») et ADDIU («Add Immediate 
Unsigned Word »). 


Voici le listing d'objdump pour y regarder de plus prés: 


Listing 1.83 : GCC 4.4.5 avec optimisation (objdump) 


00400620 «main»: 
400620: 3c1c0042 lui gp,0x42 
4006a4: 27bdffe0 addiu sp,sp, -32 
4006a8: 279c8930 addiu gp,gp,-30416 


4006ac: afbf001c sw ra,28(sp) 
4006b0:  afb00018 sw s0,24(sp) 
4006b4: afbc0010 sw gp,16(sp) 
4006b8: 8f998034 lw t9,-32716(9p) 
4006bc: 3c040040 lui a0,0x40 


4006c0: 0320f809 jalr t9 
4006c4: 248408d0 addiu  a0,a0,2256 


4006c8: 8fbc0010 lw gp,16(sp) 

; préparer la partie haute de l'adresse de x: 
4006cc: 3c100041 lui s0,0x41 
4006d0: 8f998038 lw t9,-32712(9p) 
4006d4: 3c040040 lui a0,0x40 


ajouter la partie basse de l'adresse de x: 
4006d8: 26050920 addiu  a1,s0,2336 
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maintenant l'adresse de x est dans $al. 

4006dc: 0320f809 jalr t9 

4006e0: 248408dc addiu a0,a0,2268 

4006e4: 8fbc0010 lw gp,16(sp) 

; la partie haute de l'adresse de x est toujours dans $s0. 

lui ajouter la partie basse et charger un mot de la mémoire: 


4006e8: 8e050920 lw al,2336(50) 

: la valeur de x est maintenant dans $al. 
4006ec: 8f99803c lw t9,-32708(gp) 
4006f0: 3c040040 lui a0 ,0x40 


4006f4: 0320f809 jalr t9 
4006f8: 248408e0 addiu  a0,a0,2272 


4006fc: 8fbf001c lw ra,28(sp) 
400700: 00001021 move v0,zero 
400704: 8fb00018 lw s0,24(sp) 
400708: 03e00008 jr ra 


40070c: 27bd0020 addiu sp,sp,32 


Nous voyons que l'adresse est formée en utilisant LUI et ADDIU, mais la partie haute 
de l'adresse est toujours dans le registre $50, et il est possible d’encoder l'offset en 
une instruction LW («Load Word»), donc une seule instruction LW est suffisante pour 
charger une valeur de la variable et la passer a printf (). 


Les registres contenant des données temporaires sont préfixés avec T-, mais ici nous 
en voyons aussi qui sont préfixés par S-, leur contenu doit étre doit étre sauvegardé 
quelque part avant de les utiliser dans d’autres fonctions. 


C'est pourquoi la valeur de $50 a été mise a l'adresse 0x4006cc et utilisée de nou- 
veau à l'adresse 0x4006e8, aprés l'appel de scanf (). La fonction scanf () ne change 
pas cette valeur. 


1.12.4 scanf() 


Comme il a déjà été écrit, il est plutót dépassé d'utiliser scanf () aujourd'hui. Mais 
si nous devons, il faut vérifier si scanf () se termine correctement sans erreur. 


#include <stdio.h> 


int main() 
{ 
int x; 
printf ("Enter X:\n"); 


if (scanf ("%d", €x)==1) 

printf ("You entered %d...\n", x); 
else 

printf ("What you entered? Huh?\n"); 


return 0; 


118 
Par norme, la fonction scanf () /* renvoie le nombre de champs qui ont été lus avec 
SUCCES. 


Dans notre cas, si tout se passe bien et que l'utilisateur entre un nombre scanf () 
renvoie 1, ou en cas d'erreur (ou EOF”) — 0. 


Ajoutons un peu de code C pour vérifier la valeur de retour de scanf () et afficher 
un message d'erreur en cas d'erreur. 


Cela fonctionne comme attendu: 


C:\...>ex3.exe 
Enter X: 

123 

You entered 123... 


C:\...>ex3.exe 

Enter X: 

ouch 

What you entered? Huh? 


MSVC: x86 


Voici ce que nous obtenons dans la sortie assembleur (MSVC 2010) : 


lea eax, DWORD PTR _x$[ebp] 
push eax 
push OFFSET $5G3833 ; '%d', 00H 
call _scanf 
add esp, 8 
cmp eax, 1 
jne SHORT $LN2@main 
mov ecx, DWORD PTR x$[ebp] 
push ecx 
push OFFSET $5G3834 ; ‘You entered %d...', OaH, OOH 
call _printf 
add esp, 8 
jmp SHORT $LN1@main 
$LN2@main: 
push OFFSET $SG3836 ; ‘What you entered? Huh?', OaH, 00H 
call _ printf 
add esp, 4 
$LN1@main: 
xor eax, eax 


La fonction appelante (main()) a besoin du résultat de la fonction appelée, donc la 
fonction appelée le renvoie dans la registre EAX. 


Nous le vérifions avec l'aide de l'instruction CMP EAX, 1 (CoMPare). En d'autres 
mots, nous comparons la valeur dans le registre EAX avec 1. 


76scanf, wscanf: MSDN 
77End of File (fin de fichier) 
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Une instruction de saut conditionnelle JNE suit l'instruction CMP. JNE signifie Jump if 
Not Equal (saut si non égal). 


Donc, si la valeur dans le registre EAX n'est pas égale à 1, le CPU va poursuivre 
l'exécution à l'adresse mentionnée dans l'opérande JNE, dans notre cas $LN2@main. 
Passer le contrôle à cette adresse résulte en l'exécution par le CPU de printf() avec 
l'argumentWhat you entered? Huh?. Mais si tout est bon, le saut conditionnel n'est 
pas pris, et un autre appel à printf() est exécuté, avec deux arguments: 

'You entered %d...' et la valeur de x. 


Puisque dans ce cas le second printf() n'a pas été exécuté, il y a un JMP qui le 
précède (saut inconditionnel). Il passe le contrôle au point après le second printf() 
et juste avant l'instruction XOR EAX, EAX, qui implémente return 0. 


Donc, on peut dire que comparer une valeur avec une autre est usuellement im- 
plémenté par la paire d'instructions CMP/Jcc, oü cc est un code de condition. CMP 
compare deux valeurs et met les flags/? du processeur. Jcc vérifie ces flags et dé- 
cide de passer LE Contróle à l'adresse spécifiée ou non. 


Cela peut sembler paradoxal, mais l'instruction CMP est en fait un SUB (soustraction). 
Toutes les instructions arithmétiques mettent les flags du processeur, pas seulement 
CMP. Si nous comparons 1 et 1, 1- 1 donne O donc le flag ZF va étre mis (signifiant 
que le dernier résultat est 0). Dans aucune autre circonstance ZF ne sera mis, sauf 
si les opérandes sont égaux. JNE vérifie seulement le flag ZF et saute seulement 
si il n'est pas mis. JNE est un synonyme pour JNZ (Jump if Not Zero (saut si non 
zéro)). L'assembleur génére le méme opcode pour les instructions JNE et JNZ. Donc, 
l'instruction CMP peut étre remplacée par une instruction SUB et presque tout ira bien, 
à la différence que SUB altére la valeur du premier opérande. CMP est un SUB sans 
sauver le résultat, mais modifiant les flags. 


MSVC: x86: IDA 


C'est le moment de lancer IDA et d'essayer de faire quelque chose avec. À propos, 
pour les débutants, c'est une bonne idée d'utiliser l'option /MD de MSVC, qui signifie 
que toutes les fonctions standards ne vont pas étre liées avec le fichier exécutable, 
mais vont à la place être importées depuis le fichier MSVCR* DLL. Ainsi il est plus 
facile de voir quelles fonctions standards sont utilisées et oü. 


En analysant du code dans IDA, il est trés utile de laisser des notes pour soi-méme 
(et les autres). En la circonstance, analysons cet exemple, nous voyons que JNZ sera 
déclenché en cas d'erreur. Donc il est possible de déplacer le curseur sur le label, 
de presser «n » et de lui donner le nom «error». Créons un autre label—dans «exit ». 
Voici mon résultat: 


.text:00401000 main proc near 
.text:00401000 
.text:00401000 var 4 
.text:00401000 argc 
.text:00401000 argv 
.text:00401000 envp 
.text:00401000 


dword ptr -4 
dword ptr 8 
dword ptr OCh 
dword ptr 10h 


78flags x86, voir aussi: Wikipédia. 
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.text:00401000 push ebp 
.text:00401001 mov ebp, esp 
.text:00401003 push ecx 
.text:00401004 push offset Format ; "Enter X:\n" 
.text:00401009 call ds:printf 
.text:0040100F add esp, 4 
.text:00401012 lea eax, [ebp+var 4] 
.text:00401015 push eax 
.text:00401016 push offset aD ; "%d" 
.text:0040101B call ds:scanf 
.text:00401021 add esp, 8 
.text:00401024 cmp eax, 1 
.text:00401027 jnz short error 
.text:00401029 mov ecx, [ebp+var_4] 
.text:0040102C push ecx 
.text:0040102D push offset aYou ; "You entered %d...\n" 
.text:00401032 call ds:printf 
.text:00401038 add esp, 8 
.text:0040103B jmp short exit 
.text:0040103D 

.text:0040103D error: ; CODE XREF: main+27 
.text:0040103D push offset aWhat ; "What you entered? Huh?\n" 
.text:00401042 call ds:printf 
.text:00401048 add esp, 4 
.text:0040104B 

.text:0040104B exit: ; CODE XREF: main+3B 
.text:0040104B xor eax, eax 
.text:0040104D mov esp, ebp 
.text:0040104F pop ebp 
.text:00401050 retn 

.text:00401050 main endp 


Maintenant, il est légérement plus facile de comprendre le code. Toutefois, ce n'est 
pas une bonne idée de commenter chaque instruction. 


Vous pouvez aussi cacher (replier) des parties d'une fonction dans IDA. Pour faire 
cela, marquez le bloc, puis appuyez sur Ctrl-«-» sur le pavé numérique et entrez le 
texte qui doit étre affiché à la place. 


Cachons deux blocs et donnons leurs un nom: 


.text:00401000 text segment para public 'CODE' use32 
.text:00401000 assume cs: text 

.text:00401000 ;org 401000h 

.text:00401000 ; ask for X 

.text:00401012 ; get X 

.text:00401024 cmp eax, 1 

.text:00401027 jnz short error 

.text:00401029 ; print result 

.text:0040103B jmp short exit 

.text:0040103D 

.text:0040103D error: ; CODE XREF: main+27 
.text:0040103D push offset aWhat ; "What you entered? Huh?\n" 
.text:00401042 call ds:printf 
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.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00401050 main endp 


.text 


00401048 
0040104B 
0040104B 
0040104B 
0040104D 
0040104F 
00401050 


exit: 


add esp, 4 


; CODE XREF: main+3B 
xor eax, eax 

mov esp, ebp 

pop ebp 

retn 


Pour étendre les parties de code précédemment cachées. utilisez Ctrl-«4 » sur le 
pavé numérique. 
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En appuyant sur «space », nous voyons comment IDA représente une fonction sous 
forme de graphe: 


5 int  cdecl main() 
| nain proc near 


var h- dword ptr -4 
argc- dword ptr 8 

argu= dword ptr — 8Ch 
enup- dword ptr 18h 


ebp 
nou ebp, esp 

push ecx 

push offset Format ; "Enter X:Xn" 
call ds:printf 

add esp, ^ 

lea eax, [ebp*var ^] 

push eax 

push offset aD 
call ds:scanf 
add esp, 8 

cmp eax, 1 

j short error 


ae 
a 


ecx, [ebp*var 4] 

ecx "ror: ; "What you entered? Huh?\n" 
offset aVou ; “You entered %d...\n" offset aWhat 

ds:printf ds:printf 

esp, 8 esp, ^ 

short exit 


| nain endp 


Fig. 1.18: IDA en mode graphe 


Il y a deux fléches aprés chaque saut conditionnel: une verte et une rouge. La fléche 
verte pointe vers le bloc qui sera exécuté si le saut est déclenché, et la rouge sinon. 
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Il est possible de replier des noeuds dans ce mode et de leurs donner aussi un nom 
(«group nodes »). Essayons avec 3 blocs: 


; int  cdecl main() 
| nain proc near 


var_4= dword ptr -4 
argc- dword ptr 8 

argu- dword ptr  8Ch 
enup- dvord ptr 18h 


ebp 
mou ebp, esp 

push ecx 

push offset Format ; "Enter X:\n" 
call ds:printf 

add esp, ^ 

lea eax, [ebp*var 5^] 

push eax 

push offset aD ; Ud" 

call ds :scanf 
add esp, 8 

cmp eax, 1 

j short error 


HNu HA | 


Fig. 1.19: IDA en mode graphe avec 3 nœuds repliés 


C'est très pratique. On peut dire qu'une part importante du travail des rétro-ingénieurs 
(et de tout autre chercheur également) est de réduire la quantité d'information avec 
laquelle travailler. 
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MSVC: x86 + OllyDbg 


Essayons de hacker notre programme dans OllyDbg, pour le forcer á penser que 
scanf () fonctionne toujours sans erreur. Lorsque l'adresse d'une variable locale est 
passée a scanf (), la variable contient initiallement toujours des restes de données 
aléatoires, dans ce cas 0x6E494714 : 


CPU - main thread, module ex3 


«Printf>] 


' 00321015 


Bt FFFFFFFF) 

BC FFFFFFFF) 

` t ØLFFFFFFFF) 

el " : ; B(FFFFFFFF) 
TEFDDOBOLFFF) 


DUO m  mmmmmmmrmmtm 


Stack [0042FBD0]=e43. 00323000, ; O 
E t G(FFFFFFFF) 


r? 
entered 
What yot 


8 "rt 
Hiẹ hN 


aaaaaaaa 


Fig. 1.20: OllyDbg : passer l'adresse de la variable à scanf() 
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Lorsque scanf () s'exécute dans la console, entrons quelque chose qui n'est pas du 
tout un nombre, comme «asdasd ». scanf () termine avec 0 dans EAX, ce qui indique 
qu'une erreur s'est produite. 


Nous pouvons vérifier la variable locale dans le pile et noter qu'elle n'a pas changé. 
En effet, qu'aurait écrit scanf () ici? Elle n'a simplement rien fait à part renvoyer 
zéro. 


Essayons de «hacker » notre programme. Clique-droit sur EAX, parmi les options il y 
a «Set to 1» (mettre à 1). C'est ce dont nous avons besoin. 


Nous avons maintenant 1 dans EAX, donc la vérification suivante va s'exécuter comme 
souhaiter et printf() va afficher la valeur de la variable dans la pile. 


Lorsque nous lancons le programme (F9) nous pouvons voir ceci dans la fenétre de 
la console: 


Listing 1.84 : fenétre console 


Enter X: 
asdasd 
You entered 1850296084... 


En effet, 1850296084 est la représentation en décimal du nombre dans la pile (0x6E494714)! 
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MSVC: x86 + Hiew 


Cela peut également étre utilisé comme un exemple simple de modification de fichier 
exécutable. Nous pouvons essayer de modifier l'exécutable de telle sorte que le 
programme va toujours afficher notre entrée, quelle qui'elle soit. 


En supposant que l'exécutable est compilé avec la bibliothèque externe MSVCR* . DLL 
(i.e., avec l'option /MD) 7°, nous voyons la fonction main() au début de la section 
.text. Ouvrons l'exécutable dans Hiew et cherchons le début de la section .text 
(Enter, F8, F6, Enter, Enter). 


Nous pouvons voir cela: 


C:\Polygon\ollydbg\ex3.exe a32 PE .00401000 |Hie 
.00401000: ebp 
.00401001: ebp,esp 
-.00401003: ecx 
.00401004: 
.00401009: printf 
.0040100F: 83C404 esp, 
.00401012: 8D45FC eax, [ebp][-4] 
.00401015: 50 eax 
.00401016: 68 --B 
.0040101B: FF15 scanf 
.00401021: 830408 esp, 
.00401024: 83F801 eax, 
.00401027: 7514 j --B 
.00401029: 8BADFC ecx, [ebp][-4] 
.0040102C: 51 ecx 
.0040102D: 68 ;' You entered Xd...' 
.00401032: FF15 
.00401038: 83C408 
.0040103B: EBOE 
.0040103D: 68 
.00401042: FF15 
.00401048: 83C404 
.0040104B: 33C0 
.0040104D: 8BE5 esp,ebp 
.0040104F: 5D ebp 
.00401050: C3 : A-ALALALALALALA 
.00401051: B84D5A0000 
2FilBlk 


Fig. 1.21: Hiew: fonction main() 


Hiew trouve les chaîne ASCIIZ® et les affiche, comme il le fait avec le nom des 
fonctions importées. 


79c'est aussi appelé «dynamic linking » 
80ASCII Zero ( chaine ASCII terminée par un octet nul (à zéro)) 
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Déplacez le curseur à l'adresse .00401027 (où se trouve l'instruction JNZ, que l'on 
doit sauter), appuyez sur F3, et ensuite tapez «9090 » (qui signifie deux NOPs) : 


C:\Polygon\ollydbg\ex3.exe BIFWO EDITMODE a32 PE 0000 
00000400: 55 ebp 
00000401: 8BEC ebp,esp 
00000403: 51 ecx 
00000404: 68 ; @0 ‘ 
00000409: FF1554. d, [000402094] 
0000040F: 83C404 esp, 
00000412: 8D45FC eax, [ebp][-4] 
00000415: 50 eax 
00000416: 68 ; qQesm' 
0000041B: FF158C: d, [00040208C] 
00000421: 83C408 esp, 
00000424: 83F801 eax, 
00000427: 90 
00000428: 90 
00000429: 8B4DFC ecx, [ebp][-4] 
0000042C: 51 ecx 
0000042D: 68 ;" @0E' 
00000432: FF15 d, [000402094] 
00000438: 83C408 esp, 
0000043B: EBOE 
0000043D: 68 ; Qe$' 
00000442: FF15 d, [000402094] 
00000448: 83C404 esp, 
0000044B: 33C0 eax,eax 
0000044D: 8BE5 esp,ebp 
0000044F : ebp 


A_A_A_A_A_A_A_A_A_A_A_A_A 


Fig. 1.22: Hiew: remplacement de JNZ par deux NOPs 


Appuyez sur F9 (update). Maintenant, l'exécutable est sauvé sur le disque. ll va se 
comporter comme nous le voulions. 


Deux NOPs ne constitue probablement pas l'approche la plus esthétique. Une autre 
facon de modifier cette instruction est d'écrire simplement O dans le second octet 
de l'opcode ((jump offset), donc ce JNZ va toujours sauter à l'instruction suivante. 


Nous pouvons également faire le contraire: remplacer le premier octet avec EB sans 
modifier le second octet (jump offset). Nous obtiendrions un saut inconditionnel qui 
est toujours déclenché. Dans ce cas le message d'erreur sera affiché à chaque fois, 
peu importe l'entrée. 
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MSVC: x64 


Puisque nous travaillons ici avec des variables typées int, qui sont toujours 32-bit en 
x86-64, nous voyons comment la partie 32-bit des registres (préfixés avec E-) est 
également utilisée ici. Lorsque l'on travaille avec des ponteurs, toutefois, les parties 
64-bit des registres sont utilisées, préfixés avec R-. 


Listing 1.85 : MSVC 2012 x64 


DATA | SEGMENT 


$SG2924 DB ‘Enter X:', OaH, 00H 
$SG2926 DB '%d', OOH 
$SG2927 DB 'You entered %d...', OaH, 00H 
$SG2929 DB ‘What you entered? Huh?', 0aH, 00H 
DATA ENDS 
TEXT | SEGMENT 
x$ = 32 
main PROC 
$LN5: 
sub rsp, 56 
lea rcx, OFFSET FLAT:$SG2924 ; ‘Enter X:' 
call printf 
lea rdx, QWORD PTR x$[rsp] 
lea rcx, OFFSET FLAT:$SG2926 ; '%d' 
call scanf 
cmp eax, 1 
jne SHORT $LN2@main 
mov edx, DWORD PTR x$[rsp] 
lea rcx, OFFSET FLAT:$SG2927 ; ‘You entered %d...' 
call printf 
jmp SHORT $LN1@main 
$LN2@main: 
lea rcx, OFFSET FLAT:$SG2929 ; ‘What you entered? Huh?' 
call printf 
$LN1@main: 
; retourner 0 
xor eax, eax 
add rsp, 56 
ret 0 
main ENDP 
TEXT ENDS 
END 
ARM 


ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.86 : avec optimisation Keil 6/2013 (Mode Thumb) 


var 8 - -8 


PUSH 


{R3,LR} 


WO U1 S UN) HÀ 
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ADR RO, aEnterX ; "Enter X:\n" 
BL __2printf 
MOV R1, SP 
ADR RO, aD ; "sq" 
BL _ Oscanf 
CMP RO, #1 
BEQ loc 1E 
ADR RO, aWhatYouEntered ; "What you entered? Huh?\n" 
BL _ 2printf 
loc 1A ; CODE XREF: main+26 
MOVS RO, £0 
POP {R3,PC} 
loc 1E ; CODE XREF: main+12 
LDR R1, [SP,#8+var 8] 
ADR RO, aYouEnteredD___ ; "You entered %d...\n" 
BL _ 2printf 
B loc 1A 


Les nouvelles instructions sont CMP et BEQ?!, 


CMP est similaire à l'instruction x86 du méme nom, elle soustrait l'un des arguments 
à l'autre et met à jour les flags si nécessaire. 


BEQ saute à une autre adresse si les opérandes étaient égaux l'un à l'autre, ou, si 
le résultat du dernier calcul était 0, ou si le flag Z est à 1. Elle se comporte comme 
JZ en x86. 


Tout le reste est simple: le flux d'exécution se sépare en deux branches, puis les 
branches convergent vers le point où 0 est écrit dans le registre RO comme valeur 
de retour de la fonction, et cette derniére se termine. 


ARM64 
Listing 1.87 : GCC 4.9.1 ARM64 sans optimisation 
.LC0: 
.string "Enter X:" 
.LC1: 
.string "sd" 
.LC2: 
.string "You entered %d...\n" 
.LC3: 
.string "What you entered? Huh?" 
f6: 
; sauver FP et LR dans la structure de pile locale: 
stp x29, x30, [sp, -32]! 
; définir la pile locale (FP=SP) 
add x29, sp, 0 


; charger le pointeur sur la chaine "Enter X:": 


8l (PowerPC, ARM) Branch if Equal 
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adrp x0, .LCO 
add x0, x0, :1012:.LCO0 
bl puts 
charger le pointeur sur la chaine "%d": 
adrp x0, .LC1 


add x0, x0, :lo12:.LC1 

; calculer l'adresse de la variable x dans la pile locale 
add x1, x29, 28 
bl . isoc99 scanf 


; scanf() renvoie son résultat dans WO. 
le vérifier: 
cmp wO, 1 
BNE est Branch if Not Equal (branchement si non égal) 
; donc if WO<>1, un saut en L2 sera effectué 
bne .L2 
; à ce point W0-1, signifie pas d'erreur 
charger la valeur de x depuis la pile locale 
ldr wl, [x29,28] 
charger le pointeur sur la chaîne "You entered %d...\n": 
adrp x0, .LC2 


add x0, x0, :lo12:.LC2 
bl printf 

; sauter le code, qui affiche la chaíne "What you entered? Huh?": 
b .L3 


.L2: 
; charger le pointeur sur la chaîne "What you entered? Huh?": 
adrp x0, .LC3 


add x0, x0, :1012:.LC3 
bl puts 

.L3: 

; retourner 0 
mov w0, 0 

; restaurer FP et LR: 
ldp x29, x30, [sp], 32 
ret 


Dans ce cas, le flux de code se sépare avec l'utilisation de la paire d'instructions 
CMP/BNE (Branch if Not Equal) (branchement si non égal). 


MIPS 


Listing 1.88 : avec optimisation GCC 4.4.5 (IDA) 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


004006A0 main: 
004006A0 
004006A0 var 18 
004006A0 var 10 
004006A0 var 4 
004006A0 
004006A0 
004006A4 
004006A8 
004006AC 


-0x18 
-0x10 


f 
D 


~ 
c 
H- 


$gp, 
addiu  $sp, 
$gp, 
$ra, 


n ana 
£ H- 


0x42 

-0x28 

0x418960 
Ox28+var_4($sp) 
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.text:004006B0 SW $gp, Ox28+var 18($sp) 

. text: 004006B4 la $t9, puts 

. text: 004006B8 lui $a0, 0x40 

.text:004006BC jalr $t9 ; puts 

.text:004006C0 la $a0, aEnterX # "Enter X:" 

. text : 004006C4 lw $gp, Ox28+var 18($sp) 

.text:004006C8 lui $a0, 0x40 

.text:004006CC la $t9, — isoc99 scanf 

.text:004006D0 la $a0, aD H "sd" 

.text:004006D4 jalr $t9 ; isoc99 scanf 

.text:004006D8 addiu $al, $sp, Ox28+var 10 # branch delay slot 

.text:004006DC li $v1, 1 

.text : 004006E0 lw $gp, Ox28+var 18($sp) 

.text :004006E4 beq $vO, $v1, loc 40070C 

. text: 004006E8 or $at, $zero # branch delay slot, NOP 

. text: 004006EC la $t9, puts 

.text:004006F0 lui $a0, 0x40 

.text:004006F4 jalr $t9 ; puts 

.text:004006F8 la $a0, aWhatYouEntered # "What you entered? 

an 

text: 004006FC lw $ra, Ox28+var 4($sp) 

.text:00400700 move $vO, $zero 

. text: 00400704 jr $ra 

. text: 00400708 addiu $sp, 0x28 

.text:0040070C loc 40070C: 

.text:0040070C la $t9, printf 

.text:00400710 lw $al, 0x28+var_10($5p) 

.text:00400714 lui $a0, 0x40 

.text:00400718 jalr $t9 ; printf 

.text:0040071C la $a0, aYouEnteredD # "You entered 
%d... Nn" 

.text:00400720 lw $ra, 0x28+var_4($5p) 

.text:00400724 move $vO, $zero 

.text:00400728 jr $ra 

.text:0040072C addiu  $sp, 0x28 


scanf() renvoie le résultat de son traitement dans le registre $VO. Il est testé à 
l'adresse 0x004006E4 en comparant la valeur dans $VO avec celle dans $V1 (1 a 
été stocké dans $V1 plus tót, en 0x004006DC). BEQ signifie «Branch Equal» (bran- 
chement si égal). Si les deux valeurs sont égales (i.e., succes), l'exécution saute à 
l'adresse 0x0040070C. 


Exercice 


Comme nous pouvons voir, les instructions JNE/JNZ peuvent facilement étre rempla- 
cées par JE/JZ et vice-versa (ou BNE par BEQ et vice-versa). Mais les blocs de base 
doivent aussi étre échangés. Essayez de faire cela pour quelques exemples. 


1.12.5 Exercice 
* http://challenges.re/53 
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1.13 Intéressant à noter: variables globales vs. lo- 


cales 


Maintenant vous savez que les variables globales sont remplies avec des zéros par 
l'OS au début (1.12.3 on page 106, [ISO/IEC 9899:TC3 (C C99 standard), (2007)6.7.8p10]), 
mais que les variables locales ne le sont pas. 


Parfois, vous avez une variable globale que vous avez oublié d'initialiser et votre pro- 
gramme fonctionne gráce au fait qu'elle est a zéro au début. Puis, vous éditez votre 
programme et déplacez la variable globale dans une fonction pour la rendre locale. 
Elle ne sera plus initialisée a zéro et ceci peut résulter en de méchants bogues. 


1.14 Accéder aux arguments passés 


Maintenant nous savons que la fonction appelante passe les arguments à la fonction 
appelée par la pile. Mais comment est-ce que la fonction appelée y accéde? 


Listing 1.89 : exemple simple 


#include <stdio.h> 
int f (int a, int b, int c) 
{ 
return a*b+c; 
}; 
int main() 
{ 
printf ("%d\n", f(1, 2, 3)); 
return 0; 
}; 
1.14.1 x86 
MSVC 


Voici ce que l'on obtient aprés compilation (MSVC 2010 Express) : 


Listing 1.90 : MSVC 2010 Express 


TEXT | SEGMENT 

_a$ = 8 ; taille = 4 

_b$ = 12 ; taille = 4 

_c$ = 16 ; taille = 4 

_f PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR a$[ebp] 
imul eax, DWORD PTR b$[ebp] 
add eax, DWORD PTR _c$[ebp] 
pop ebp 
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ret 0 
f ENDP 
_main PROC 
push ebp 
mov ebp, esp 
push 3 ; 3ème argument 
push 2 ; 2ème argument 
push 1 ; ler argument 
call f 
add esp, 12 
push eax 
push OFFSET $5G2463 ; '%d', 0aH, 00H 
call _printf 
add esp, 8 
; retourner 0 
xor eax, eax 
POP ebp 
ret 0 
main  ENDP 


Ce que l'on voit, c'est que la fonction main() pousse 3 nombres sur la pile et appelle 
f(int,int,int). 


L'accés aux arguments à l'intérieur de f() est organisé à l'aide de macros comme: 
_a$ = 8, de la méme facon que pour les variables locales, mais avec des offsets 
positifs (accédés avec plus). Donc, nous accédons à la partie hors de la structure 
locale de pile en ajoutant la macro _a$ à la valeur du registre EBP. 


Ensuite, la valeur de a est stockée dans EAX. Aprés l'exécution de l'instruction IMUL, 
la valeur de EAX est le produit de la valeur de EAX et du contenu de b. 


Aprés cela, ADD ajoute la valeur dans c à EAX. 


La valeur dans EAX n'a pas besoin d'étre déplacée/copiée : elle est déjà là oü elle 
doit étre. Lors du retour dans la fonction appelante, elle prend la valeur dans EAX et 
l'utilise comme argument pour printf(). 


MSVC + OllyDbg 


Illustrons ceci dans OllyDbg. Lorsque nous traçons jusqu'à la première instruction 
de f() qui utilise un des arguments (le premier), nous voyons qu'EBP pointe sur la 
structure de pile locale, qui est entourée par un rectangle rouge. 


Le premier élément de la structure de pile locale est la valeur sauvegardée de EBP, 
le second est RA, le troisiéme est le premier argument de la fonction, puis le second 
et le troisieme. 


Pour accéder au premier argument de la fonction, on doit ajouter exactement 8 (2 
mots de 32-bit) á EBP. 


OllyDbg est au courant de cela, c'est pourquoi il a ajouté des commentaires aux 
éléments de la pile comme 
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«RETURN from » et «Argl = ...», etc. 


N.B.: Les arguments de la fonction ne font pas partie de la structure de pile de la 
fonction, ils font plutót partie de celle de la fonction appelante. 


Par conséquent, OllyDbg a marqué les éléments comme appartenant à une autre 
structure de pile. 


read, module ex 


55 PUSH EBP 

SBEC MOU EBP,ESP 

8B45 88 MOU EAX, DWORD PTR SS: CARG. 11 
BFAF45 GC IMUL EAX, DWORD PTR SS: CARG.2] 
ADD ERA» DUORD PTR SS: [ARG.3] 


IE uu 


MOU EBP,ESP 
PUSH 3 


' 66201863 00201003 


PUSH 2 C ø 902 @( FFFFFFFF) 


PUSH 1 : 
CALL GG2D1000 ; oq nta 


ADD ESP, ØC 1 OLFFFFFFFF) 
2: 7EFDDGaatFFF) 
OCFFFFFFFF) 


n 


LastErr ER 
6 (NO,NB.E,B 


OO 


Fig. 1.23: OllyDbg : à l'intérieur de la fonction f () 


GCC 
Compilons le même code avec GCC 4.4.1 et regardons le résultat dans IDA : 


Listing 1.91 : GCC 4.4.1 


public f 
f proc near 


arg 0 = dword ptr 8 


arg 4 = dword ptr OCh 

arg 8 = dword ptr 10h 
push ebp 
mov ebp, esp 
mov eax, [ebp+arg 0] ; ler argument 
imul eax, [ebp+arg 4] ; 2eme argument 
add eax, [ebp+arg_8] ; 3eme argument 
pop ebp 
retn 

f endp 


public main 
main proc near 
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var 10 = dword ptr -10h 
var C = dword ptr -OCh 
var 8 = dword ptr -8 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 10h 
mov [esp+10h+var_8], 3 ; 3eme argument 
mov [esp+10h+var_C], 2 ; 2eme argument 
mov [esp+10h+var 10], 1 ; ler argument 
call f 
mov edx, offset aD ; "“%d\n" 
mov [esp+10h+var C], eax 
mov [esp+10h+var_10], edx 
call _printf 
mov eax, 0 
leave 
retn 
main endp 


Le résultat est presque le même, avec quelques différences mineures discutées pré- 
cédemment. 


Le pointeur de pile n'est pas remis après les deux appels de fonction (f et printf), car 
la pénultiéme instruction LEAVE (.1.6 on page 1332) s'en occupe à la fin. 


1.14.2 x64 


Le scénario est un peu différent en x86-64. Les arguments de la fonction (les 4 ou 6 
premiers d'entre eux) sont passés dans des registres i.e. l'appelée les lit depuis des 
registres au lieu de les lire dans la pile. 

MSVC 

MSVC avec optimisation : 


Listing 1.92 : MSVC 2012 x64 avec optimisation 


$SG2997 DB '*d', OaH, OOH 

main PROC 
sub rsp, 40 
mov edx, 2 
lea r8d, QWORD PTR [rdx+1] ; R8D=3 
lea ecx, QWORD PTR [rdx-1] ; ECX=1 
call f 
lea rcx, OFFSET FLAT:$SG2997 ; '%d' 
mov edx, eax 
call printf 
xor eax, eax 


add rsp, 40 


136 


ret 0 
main ENDP 
f PROC 


; ECX - ler argument 
; EDX - 2éme argument 
; R8D - 3éme argument 


imul ecx, edx 
lea eax, DWORD PTR [r8+rcx] 
ret 0 

f ENDP 


Comme on peut le voir, la fonction compacte f() prend tous ses arguments dans 
des registres. 


La fonction LEA est utilisée ici pour l'addition, apparemment le compilateur considére 
qu'elle plus rapide que ADD. 


LEA est aussi utilisée dans la fonction main() pour préparer le premier et le troisiéme 
argument de f (). Le compilateur doit avoir décidé que cela s'exécutera plus vite que 
la facon usuelle ce charger des valeurs dans les registres, qui utilise l'instruction MOV. 


Regardons ce qu'a généré MSVC sans optimisation: 
Listing 1.93 : MSVC 2012 x64 


f proc near 


; shadow space: 


arg 0 - dword ptr 8 
arg 8 = dword ptr 10h 
arg 10 = dword ptr 18h 
; ECX - ler argument 
; EDX - 2éme argument 
; R8D - 3éme argument 
mov [rsp+arg_10], r8d 
mov [rsptarg 8], edx 
mov [rsp+arg_0], ecx 
mov eax, [rsp+arg 0] 
imul eax, [rsp+arg_8] 
add eax, [rsp+arg 10] 
retn 
f endp 
main proc near 
sub rsp, 28h 
mov r8d, 3 ; 3rd argument 
mov edx, 2 ; 2nd argument 
mov ecx, 1 ; 1st argument 
call f 
mov edx, eax 
lea rcx, $5G2931 ; "Sdn" 


call printf 
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; retourner 0 
xor eax, eax 
add rsp, 28h 
retn 

main endp 


C'est un peu déroutant, car les 3 arguments dans des registres sont sauvegardés 
sur la pile pour une certaine raison. Ceci est appelé «shadow space» ê? : chaque 
Win64 peut (mais ce n'est pas requis) y sauver les 4 registres. Ceci est fait pour deux 
raisons: 1) c'est trop généreux d'allouer un registre complet (et méme 4 registres) 
pour un argument en entrée, donc il sera accédé par la pile; 2) le debugger sait 
toujours où trouver les arguments de la fonction lors d'un arrêt 9. 


Donc, de grosses fonctions peuvent sauvegarder leurs arguments en entrée dans 
le «shadow space » si elle veulent les utiliser pendant l'exécution, mais quelques 
petites fonctions (comme la notre) peuvent ne pas le faire. 


C'est la responsabilité de l'appelant d'allouer le «shadow space » sur la pile. 


GCC 
GCC avec optimisation génére du code plus ou moins compréhensible: 


Listing 1.94 : GCC 4.4.6 x64 avec optimisation 


f: 
; EDI - ler argument 
; ESI - 2éme argument 
; EDX - 3éme argument 
imul esi, edi 
lea eax, [rdx+rsi] 
ret 
main: 
sub rsp, 8 
mov edx, 3 
mov esi, 2 
mov edi, 1 
call f 
mov edi, OFFSET FLAT:.LCO ; "%d\n" 
mov esi, eax 
xor eax, eax ; nombre de registres vectoriel passés 
call printf 
xor eax, eax 
add rsp, 8 
ret 


GCC sans optimisation : 


Listing 1.95 : GCC 4.4.6 x64 
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f: 
; EDI - ler argument 
; ESI - 2éme argument 
; EDX - 3éme argument 
push rbp 
mov rbp, rsp 
mov DWORD PTR [rbp-4], edi 
mov DWORD PTR [rbp-8], esi 
mov DWORD PTR [rbp-12], edx 
mov eax, DWORD PTR [rbp-4] 
imul eax, DWORD PTR [rbp-8] 
add eax, DWORD PTR [rbp-12] 
leave 
ret 
main: 
push rbp 
mov rbp, rsp 
mov edx, 3 
mov esi, 2 
mov edi, 1 
call f 
mov edx, eax 
mov eax, OFFSET FLAT:.LCO ; "“%d\n" 
mov esi, edx 
mov rdi, rax 
mov eax, 0 ; nombre de registres vectoriel passés 
call printf 
mov eax, 0 
leave 
ret 


Il n'y a pasd'exigeance de «shadow space » en System V *NIX ([Michael Matz, Jan Hu- 
bicka, Andreas Jaeger, Mark Mitchell, System V Application Binary Interface. AMD64 
Architecture Processor Supplement, (2013)] ?^), mais l'appelée peut vouloir sauve- 
garder ses arguments quelque part en cas de manque de registres. 


GCC: uint64 t au lieu de int 


Notre exemple fonctionne avec des int 32-bit, c'est pourquoi c'est la partie 32-bit 
des registres qui est utilisée (préfixée par E- ). 


Il peut être légèrement modifié pour utiliser des valeurs 64-bit: 


#include <stdio.h> 
#include <stdint.h> 


uint64 t f (uint64 t a, uint64 t b, uint64 t c) 
1 


84Aussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64-abi.pdf 


return a*b+c; 
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int main() 
1 
printf ("%lld\n", f(0x1122334455667788, 
0x1111111122222222, 
0x3333333344444444)); 


return 0; 
}; 
Listing 1.96 : GCC 4.4.6 x64 avec optimisation 
f proc near 
imul rsi, rdi 
lea rax, [rdx+rsi] 
retn 
f endp 
main proc near 
sub rsp, 8 
mov rdx, 3333333344444444h ; 3eme argument 
mov rsi, 1111111122222222h ; 2eme argument 
mov rdi, 1122334455667788h ; ler argument 
call f 
mov edi, offset format ; “%slld\n" 
mov rsi, rax 
xor eax, eax ; nombre de registres vectoriel passés 
call _ printf 
xor eax, eax 
add rsp, 8 
retn 
main endp 


Le code est le méme, mais cette fois les registres complets (préfixés par R-) sont 
utilisés. 


1.14.3 ARM 

sans optimisation Keil 6/2013 (Mode ARM) 
.text:000000A4 00 30 AO El MOV R3, RO 
.text:000000A8 93 21 20 EO MLA RO, R3, R1, R2 
.text:000000AC 1E FF 2F El BX LR 
.text:000000B0 main 

.text:000000B0 10 40 2D E9 STMFD SP!, {R4,LR} 
.text:000000B4 03 20 AO E3 MOV R2, +3 
.text:000000B8 02 10 AO E3 MOV R1, #2 
.text:000000BC 01 00 AO E3 MOV RO, +1 
.text:000000C0 F7 FF FF EB BL f 
.text:000000C4 00 40 AO E1 MOV R4, RO 
.text:000000C8 04 10 AO El MOV R1, R4 


.text:000000CC 5A OF 8F E2 ADR RO, aD 0 ; "*dn" 
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.text:000000D0 E3 18 00 EB BL _ 2printf 
.text:000000D4 00 00 AO E3 MOV RO, #0 
.text:000000D8 10 80 BD E8 LDMFD SP!, {R4,PC} 


La fonction main() appelle simplement deux autres fonctions, avec trois valeurs 
passées à la première —(f()). 


Comme il y déjà été écrit, en ARM les 4 premiéres valeurs sont en général passées 
par les 4 premiers registres (RO-R3). 


La fonction f(), comme il semble, utilise les 3 premiers registres (RO-R2) comme 
arguments. 


L'instruction MLA (Multiply Accumulate) multiplie ses deux premiers opérandes (R3 
et R1), additionne le troisiéme opérande (R2) au produit et stocke le résultat dans 
le registre zéro (R0), par lequel, d'aprés le standard, les fonctions retournent leur 
résultat. 


La multiplication et l'addition en une fois (Fused multiply-add) est une instruction 
trés utile. A propos, il n'y avait pas une telle instruction en x86 avant les instructions 
FMA apparues en SIMD $”. 


La toute premiere instruction MOV R3, RO, est, apparemment, redondante (car une 
seule instruction MLA pourrait étre utilisée à la place ici). Le compilateur ne l'a pas 
optimisé, puisqu'il n'y a pas l'option d'optimisation. 


L'instruction BX rend le contróle à l'adresse stockée dans le registre LR et, si néces- 
saire, change le mode du processeur de Thumb à ARM et vice versa. Ceci peut étre 
nécessaire puisque, comme on peut le voir, la fonction f() n'est pas au courant 
depuis quel sorte de code elle peut étre appelée, ARM ou Thumb. Ainsi, si elle est 
appelée depuis du code Thumb, BX ne va pas seulement retourner le contróle à la 
fonction appelante, mais également changer le mode du processeur à Thumb. Ou ne 
pas changer si la fonction a été appelée depuis du code ARM [ARM(R) Architecture 
Reference Manual, ARMv7-A and ARMv7-R edition, (2012)A2.3.2]. 


avec optimisation Keil 6/2013 (Mode ARM) 


.text:00000098 f 
.text:00000098 91 20 20 EO MLA RO, R1, RO, R2 
.text:0000009C 1E FF 2F El BX LR 


Et voilà la fonction f () compilée par le compilateur Keil en mode optimisation maxi- 
male (-03). 


L'instruction MOV a été supprimée par l'optimisation (ou réduite) et maintenant MLA 
utilise tout les registres contenant les données en entrée et place ensuite le résultat 
directement dans R0, exactement oü la fonction appelante va le lire et l'utiliser. 


avec optimisation Keil 6/2013 (Mode Thumb) 


85Wikipédia 
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.text:0000005E 48 43 MULS RO, R1 
.text:00000060 80 18 ADDS RO, RO, R2 
.text:00000062 70 47 BX LR 


L'instruction MLA n'est pas disponible dans le mode Thumb, donc le compilateur gé- 
nére le code effectuant ces deux opérations (multiplication et addition) séparément. 


Tout d'abord, la première instruction MULS multiplie RO par R1, laissant le résultat 
dans le registreRO. La seconde instruction (ADDS) ajoute le résultat et R2 laissant le 
résultat dans le registre RO. 


ARM64 

GCC (Linaro) 4.9 avec optimisation 

Tout ce qu'il y a ici est simple. MADD est juste une instruction qui effectue une multi- 
plication/addition fusionnées (similaire à l'instruction MLA que nous avons déjà vue). 


Tous les 3 arguments sont passés dans la partie 32-bit de X-registres. Effectivement, 
le type des arguments est int 32-bit. Le résultat est renvoyé dans WO. 


Listing 1.97 : GCC (Linaro) 4.9 avec optimisation 


f: 
madd w0, WO, wl, w2 
ret 
main: 
; sauver FP et LR dans la pile locale: 
stp x29, x30, [sp, -16]! 
mov w2, 3 
mov wl, 2 
add x29, sp, 0 
mov w0, 1 
bl f 
mov wl, wO 
adrp x0, .LC7 
add x0, x0, :lo12:.LC7 
bl printf 
; retourner 0 
mov w0, 0 
; restaurer FP et LR 
ldp x29, x30, [sp], 16 
ret 
.LC7: 


.string "%d\n" 


Étendons le type de toutes les données à 64-bit uint64 t et testons: 


#include <stdio.h> 
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#include «stdint.h» 


uint64 t f (uint64 t a, uint64 t b, uint64 t c) 


1 
return a*b+c; 
}; 
int main() 
{ 
printf ("%lld\n", f(0x1122334455667788, 
0x1111111122222222, 
0x3333333344444444) ); 
return 0; 
}; 
f: 
madd x0, x0, x1, x2 
ret 
main: 
mov x1, 13396 
adrp x0, .LC8 
stp x29, x30, [sp, -16]! 
movk x1, 0x27d0, lsl 16 
add x0, x0, :lo12:.LC8 
movk x1, 0x122, lsl 32 
add x29, sp, 0 
movk x1, 0x58be, lsl 48 
bl printf 
mov w0, 0 
ldp x29, x30, [sp], 16 
ret 
.LC8: 


.string "#lld\n" 


La fonction f() est la méme, seulement les X-registres 64-bit sont utilisés entiére- 
ment maintenant. Les valeurs longues sur 64-bit sont chargées dans les registres 
par partie, c'est également décrit ici: 1.39.3 on page 570. 


GCC (Linaro) 4.9 sans optimisation 


Le code sans optimisation est plus redondant: 


f: 
sub sp, sp, £16 
str w0, [sp,12] 
str wl, [sp,8] 
str w2, [sp,4] 
ldr wl, [sp,12] 


ldr w0, [sp,8] 
mul wl, wl, wO 
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ldr wO, [sp,4] 


add w0, wl, w0 
add sp, sp, 16 
ret 


Le code sauve ses arguments en entrée dans la pile locale, dans le cas où quelqu'un 
(ou quelque chose) dans cette fonction aurait besoin d'utiliser les registres WO... .W2. 
Cela évite d'écraser les arguments originels de la fonction, qui pourraient étre de 
nouveau utilisés par la suite. 


Cela est appelé Zone de sauvegarde de registre. [Procedure Call Standard for the 
ARM 64-bit Architecture (AArch64), (2013)]®°. L'appelée, toutefois, n'est pas obligée 
de les sauvegarder. C'est un peu similaire au «Shadow Space » : 1.14.2 on page 137. 


Pourquoi est-ce que GCC 4.9 avec l'option d'optimisation supprime ce code de sau- 
vegarde? Parce qu'il a fait plus d'optimisation et en a conclu que les arguments de 
la fonction n'allaient pas être utilisés par la suite et donc que les registres WO. . .W2 
ne vont pas étre utilisés. 


Nous avons donc une paire d'instructions MUL/ADD au lieu d'un seul MADD. 


1.14.4 MIPS 


Listing 1.98 : GCC 4.4.5 avec optimisation 


.text:00000000 f: 


; $a0=a 

; $al=b 

; $a2=c 

.text:00000000 mult $al, $a0 

.text:00000004 mflo $v0 

.text:00000008 jr $ra 

.text:0000000C addu $vO, $a2, $v0 ; Slot de délai de 


branchement , 
; au retour le résultat est dans $v0 


.text:00000010 main: 
.text:00000010 


.text:00000010 var 10 = -0x10 

.text:00000010 var 4 = -4 

.text:00000010 

.text:00000010 lui $gp, ( gnu local gp >> 16) 
.text:00000014 addiu $sp, -0x20 

. text: 00000018 la $gp, ( gnu local gp € OxFFFF) 
.text:0000001C sw $ra, Ox20+var 4($sp) 

. text : 00000020 SW $gp, 0x20+var_10($sp) 

; définir c: 

.text:00000024 li $a2, 3 

; définir a: 

.text:00000028 li $a0, 1 

.text:0000002C jal f 

; définir b: 


86 Aussi disponible en http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B _ 
aapcs64.pdf 
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. text: 00000030 li 


branchement 


$al, 


2 ; slot de délai de 


; le résultat est maintenant dans $v0 


.text:00000034 lw $gp, 
. text: 00000038 lui $a0, 
.text:0000003C lw $t9, 
.text:00000040 la $a0, 
.text:00000044 jalr $t9 


; prend le résultat de la fonction 


Ox20+var 10($sp) 

($LCO >> 16) 

(printf € OxFFFF) ($gp) 
($LCO € OXFFFF) 


f() et le passe 


; en second argument à printf(): 


.text:00000048 move $al, $v0 ; Slot de délai de 
branchement 

.text:0000004C lw $ra, Ox20+var 4($sp) 

.text : 00000050 move $v0, $zero 

.text : 00000054 jr $ra 

.text:00000058 addiu  $sp, 0x20 ; slot de délai de branchement 


Les quatre premiers arguments de la fonction sont passés par quatre registres pré- 
fixés par A-. 


Il y a deux registres spéciaux en MIPS: HI et LO qui sont remplis avec le résultat 
64-bit de la multiplication lors de l'exécution d'une instruction MULT. 


Ces registres sont accessibles seulement en utilisant les instructions MFLO et MFHI. 
Ici MFLO prend la partie basse du résultat de la multiplication et le stocke dans $VO. 
Donc la partie haute du résultat de la multiplication est abandonnée (le contenu 
du registre HI n'est pas utilisé). Effectivement: nous travaillons avec des types de 
données int 32-bit ici. 


Enfin, ADDU («Add Unsigned » addition non signée) ajoute la valeur du troisiéme ar- 
gument au résultat. 


Il y a deux instructions différentes pour l'addition en MIPS: ADD et ADDU. La diffé- 
rence entre les deux n'est pas relative au fait d'étre signé, mais aux exceptions. ADD 
peut déclencher une exception lors d'un débordement, ce qui est parfois utile?" et 
supporté en ADA LP, par exemple. ADDU ne déclenche pas d'exception lors d'un dé- 
bordement. Comme C/C++ ne supporte pas ceci, dans notre exemple nous voyons 
ADDU au lieu de ADD. 


Le résultat 32-bit est laissé dans $VO. 
Il y a une instruction nouvelle pour nous dans main() : JAL («Jump and Link »). 


La différence entre JAL et JALR est qu'un offset relatif est encodé dans la premiére 
instruction, tandis que JALR saute à l'adresse absolue stockée dans un registre 
(«Jump and Link Register »). 


Les deux fonctions f() et main() sont stockées dans le méme fichier objet, donc 
l'adresse relative de f () est connue et fixée. 


87http://blog.regehr.org/archives/1154 
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1.15 Plus loin sur le renvoi des résultats 


En x86, le résultat de l'exécution d'une fonction est d'habitude renvoyé 9? dans le 
registre EAX. 


Si il est de type octet ou un caractére (char), alors la partie basse du registre EAX 
(AL) est utilisée. Si une fonction renvoie un nombre de type float, le registre ST(0) 
du FPU est utilisé. En ARM, d'habitude, le résultat est renvoyé dans le registre RO. 


1.15.1 Tentative d'utilisation du résultat d'une fonction ren- 
voyant void 


Donc, que se passe-t-il si le type de retour de la fonction main() a été déclaré du 
type void et non pas int? Ce que l'on nomme le code de démarrage (startup-code) 
appelle main() grosso-modo de la facon suivante: 


push envp 
push argv 
push argc 
call main 
push eax 
call exit 


En d'autres mots: 


exit (main(argc,argv,envp)); 


Si vous déclarez main() comme renvoyant void, rien ne sera renvoyé explicitement 
(en utilisant la déclaration return), alors quelque chose d'inconnu, qui aura été sto- 
cké dans la registre EAX lors de l'exécution de main() sera l'unique argument de la 
fonction exit(). ll y aura probablement une valeur aléatoire, laissée lors de l'exécu- 
tion de la fonction, donc le code de retour du programme est pseudo-aléatoire. 


Illustrons ce fait: Notez bien que la fonction main() a un type de retour void : 


#include <stdio.h> 


void main() 


{ 
}; 


printf ("Hello, world!\n"); 


Compilons-le sous Linux. 


GCC 4.8.1 a remplacé printf() par puts() (nous avons vu ceci avant: 1.5.3 on 
page 29), mais c'est OK, puisque puts() renvoie le nombre de caractères écrit, tout 
comme printf(). Remarquez que le registre EAX n'est pas mis à zéro avant la fin 
de main(). 


Ceci implique que la valeur de EAX à la fin de main() contient ce que puts() y avait 
mis. 


88Voir également : MSDN: Return Values (C++) : MSDN 
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Listing 1.99 : GCC 4.8.1 


.LC0: 

.string "Hello, world!" 
main: 

push ebp 

mov ebp, esp 

and esp, -16 

sub esp, 16 

mov DWORD PTR [esp], OFFSET FLAT: .LCO 

call puts 

leave 

ret 


Écrivons un script bash affichant le code de retour: 


Listing 1.100 : tst.sh 


#!/bin/sh 
./hello_world 
echo $? 


Et lancons le: 


$ tst.sh 
Hello, world! 
14 


14 est le nombre de caracteres écrits. Le nombre de caracteres affichés est passé 


de printf(), a travers EAX/RAX, dans le «code de retour ». 


Un autre exemple dans le livre: 3.32 on page 833. 


A propos, lorsque l'on décompile du C++ dans Hex-Rays, nous rencontrons souvent 


une fonction qui se termine par un destructeur d’une classe: 


call ??1CString@@QAE@XZ ; CString:: CString(void) 


mov ecx, [esp+30h+var C] 
pop edi 

pop ebx 

mov large fs:0, ecx 

add esp, 28h 

retn 


Dans le standard C++, le destructeur ne renvoie rien, mais lorsque Hex-Rays n'en 
sait rien, et pense que le destructeur et cette fonction renvoient tout deux un int 


return CString: :~CString(&Str) ; 
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fonction? 


printf() renvoie le nombre de caractéres écrit avec succés, mais, en pratique, ce 
résultat est rarement utilisé. 


Il est aussi possible d'appeler une fonction dont la finalité est de renvoyer une valeur, 
et de ne pas l'utiliser: 


int f() 
1 
// skip first 3 random values: 
rand(); 
rand(); 
rand(); 


// and use 4th: 
return rand(); 


}; 


Le résultat de la fonction rand() est mis dans EAX, dans les quatre cas. 


Mais dans les 3 premiers, la valeur dans EAX n'est pas utilisée. 


1.15.3 Renvoyer une structure 


Revenons au fait que la valeur de retour est passée par le registre EAX. 


C'est pourquoi les vieux compilateurs C ne peuvent pas créer de fonction capable 
de renvoyer quelque chose qui ne tient pas dans un registre (d'habitude int), mais si 
besoin, les informations doivent être renvoyées via un pointeur passé en argument. 


Donc, d'habitude, si une fonction doit renvoyer plusieurs valeurs, elle en renvoie une 
seule, et le reste—par des pointeurs. 


Maintenant, il est possible de renvoyer, disons, une structure entiére, mais ce n'est 
pas encore trés populaire. Si une fonction doit renvoyer une grosse structure, la fonc- 
tion appelante doit l'allouer et passer un pointeur sur cette derniére via le premier 
argument, de maniére transparente pour le programmeur. C'est presque la méme 
chose que de passer un pointeur manuellement dans le premier argument, mais le 
compilateur le cache. 


Petit exemple: 


struct s 

1 
int a; 
int b; 
int C; 

}; 


struct s get some values (int a) 


t 


struct s rt; 
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rt.a=a+1; 
rt.b=a+2; 
rt.c=a+3; 


return rt; 


}; 


...ce que nous obtenons (MSVC 2010 /0x) : 


$13853 = 8 ; size = 4 
_a$ = 12 ; size = 4 
?get some values@@GYA?AUS@@H@Z PROC ; get some values 
mov ecx, DWORD PTR a$[esp-4] 
mov eax, DWORD PTR $T3853[esp-4] 
lea edx, DWORD PTR [ecx+1] 
mov DWORD PTR [eax], edx 
lea edx, DWORD PTR [ecx+2] 
add ecx, 3 
mov DWORD PTR [eax+4], edx 
mov DWORD PTR [eax+8], ecx 
ret 0 
?get some values@@GYA?AUS@GH@Z ENDP ; get some values 


Ici, le nom de la macro interne pour passer le pointeur sur une structure est $T3853. 


Cet exemple peut étre récrit en utilisant les extensions C99 du langage: 


struct s 
1 
int a; 
int b; 
int c; 
struct s get some values (int a) 
1 
return (struct s){.a=a+1, .b=a+2, .c=a+3}; 
}; 


Listing 1.101 : GCC 4.8.1 


get some values proc near 


ptr to struct = dword ptr 4 
a = dword ptr 8 
mov edx, [espta] 
mov eax, [esp+ptr to struct] 
lea ecx, [edx+1] 
mov [eax], ecx 
lea ecx, [edx+2] 
add edx, 3 
mov [eax+4], ecx 


mov [eax+8], edx 
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retn 
_get_some values endp 


Comme on le voit, la fonction remplit simplement les champs de la structure allouée 
par la fonction appelante, comme si un pointeur sur la structure avait été passé. 
Donc, il n'y a pas d'impact négatif sur les performances. 


1.16 Pointeurs 


1.16.1 Renvoyer des valeurs 


Les pointeurs sont souvent utilisés pour renvoyer des valeurs depuis les fonctions 
(rappelez-vous le cas (1.12 on page 91) de scanf ()). 


Par exemple, lorsqu'une fonction doit renvoyer deux valeurs. 


Exemple avec des variables globales 


#include <stdio.h> 


void f1 (int x, int y, int *sum, int *product) 
{ 
*suM=X+y; 
*product=x*y; 
}; 


int sum, product; 
void main() 
f1(123, 456, &sum, &product); 


printf ("sum=%d, product=%d\n", sum, product); 
}; 


Ceci se compile en: 


Listing 1.102 : MSVC 2010 avec optimisation (/ObO) 


COMM _ product: DWORD 

COMM _ sum: DWORD 

$5G2803 DB 'sum=%d, product=%d', OaH, OOH 

_x$ = 8 ; size = 4 

_y$ = 12 ; size = 4 

_sum$ = 16 ; Size = 4 

_product$ = 20 ; Size = 4 

_f1 PROC 
mov ecx, DWORD PTR y$[esp-4] 
mov eax, DWORD PTR _x$[esp-4] 
lea edx, DWORD PTR [eax+ecx] 


imul eax, ecx 
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_f1 


_main 


main 


mov 
push 
mov 
mov 
mov 
pop 
ret 
ENDP 


PROC 
push 
push 
push 
push 
call 
mov 
mov 
push 
push 
push 
call 
add 
xor 
ret 
ENDP 


ecx, DWORD PTR product$[esp-4] 


esi 

esi, DWORD PTR sum$[esp] 
DWORD PTR [esi], edx 
DWORD PTR [ecx], eax 

esi 

0 


OFFSET product 


OFFSET sum 

456 ; 000001c8H 
123 ; 0000007bH 
f1 


eax, DWORD PTR product 
ecx, DWORD PTR _sum 
eax 

ecx 

OFFSET $5G2803 

DWORD PTR imp printf 
esp, 28 

eax, eax 

0 
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Regardons ceci dans OllyDbg : 


CPU - main thread, module global 


PUSH OFFSET 00873388 

PUSH OFFSET 00873384 

PUSH 1C8 

6A 7B PUSH 7B 

ES CAFFFFFF | CALL 00871000 

Al 38338700 |MOU ERX,DWORD PTR DS: [8373388] 
3600 24338701 MOU ECX, DWORD PTR DS: [873384] 
5a PUSH EAX 

51 PUSH ECX 

68 00202700 |PUSH OFFSET 00873000 

FF15 9626878 CALL DWORD PTR DS: [<8MSUCR1B6.printf>] 
3304 1C ADD ESP, 1C 

aoe XOR EAX, EAX 


RETN 
PUSH 00871420 


ASCII "H(F" 
aaaaaaoa 
26080848 
GG3GF8E4 
aasar9ac 
26008881 
00873390 global. 


6987182À global 10 


D(FFFFFFFF) 

t BtFFFFFFFF) 
@( FFFFFFFF) 
@( FFFFFFFF) 
?EFDDaaatFFF) 
@(FFFFFFFF) 


DIO m mmmmmimigmgtr nl 


Stack [GoSGFSEAT-S Lo 
Imm=000001C08 (decima 


¡DOOR D AnD 


RETURN from alob. 
ASCII ”pNF” 


) 4 © TIPO 
cm 


Cc 
OOTO 


ood 


DO 


Fig. 1.24: OllyDbg : les adresses des variables globales sont passées à f1() 


Tout d'abord, les adresses des variables globales sont passées à f1(). Nous pouvons 
cliquer sur «Follow in dump » sur l'élément de la pile, et nous voyons l'espace alloué 
dans le segment de données pour les deux variables. 
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Ces variables sont mises a zéro, car les données non-initialisées (de BSS) sont effa- 
cées avant le début de l'exécution, [voir ISO/IEC 9899:TC3 (C C99 standard), (2007) 
6.7.8p10]. 


Elles se trouvent dans le segment de données, nous pouvons le vérifier en appuyant 
sur Alt-M et en regardant la carte de la mémoire: 


E 


86050006) 60904006 R 

86060006) 20861000 RW 

66078000) 68867488 R C:\WindowssSystem32s Lor 
96159866) 00007000 RW Guaj RU 
98360606 | 00961096 RU Gua; RW Gua; 
DO30E000| 20802008 Stack of main thread RW RW 
00460000| aaaacaaa Heap Priv| RW RW 
D04A0000| 00007000 Priv| RU Rul 
86680000) aaaaceaa Default heap Priv} RW RW 
00870000| 64001600) global PE header Img |R RWE Cop 
00871000| 66061606) global «text Code Img |RE RWE Cop: 
66872666 66661666 global .rdata Imports Ina |R RWE Cop: 
00873000 00001000 global „data Data Img RU o 
66874666 66661666 global .reloc Relocations Ina |R RWE Cop: 
£E3E0000| 64001600) MSUCRIGO PE header Ima |R RWE Cop 
6E3E 1908! aaap2aaa| MSUCR100 «text Code, imports, exports Im RE RWE Cop: 
6E493000| 66966006) MSUCRIGO «data Data Img | RW Cops RUE Cop: 
6E499666 66661666) MSUCR100 rere Resources Ina |R RWE Cop: 
£E49A000| aaaacaaa| MSUCRIGO .reloc Relocat ions Img |R RUE Cop: 
75500666 | 64061906) Mod_755D PE header Ina |R RWE Cop 
75501000| 00003000 Img |R E RWE Cop: 
75504000| 00001000 Ima | RW RWE Cop: 
75505000| 60883006 Img |R RWE Cop: 
755E0000| 00001000| Mod_755E PE header Img |R RWE Cop: 
755E1000| 00040000 Img |R E RWE Cop: 
7562E000| 00905606 Img | RW Copy RWE Cop 
75633000| 00009000 Img |R RWE Cop: 


Fig. 1.25: OllyDbg : carte de la mémoire 
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Tracons l'exécution (F7) jusqu'au début de f1() : 


CPU - main thread, module global Of x! 
lé P 


ORD SS: LARG. 
MOU EAX,DWORD PTR SS: CARG. 1] 
LEA EDX, CECK+EAX] 

IMUL EAX, ECX 

MOV ECX, DWORD PTR SS: [ARG. 4] 
PUSH_ESI 

MOU ESI, DWORD PTR SS: ARG. 3] 
MOV DWORD PTR DS:[ESI], EDX 
MOV DWORD PTR DS: CECK],EAX 


PUSH OFFSET 00873388 
D 0 4 


ac 


Stack LOBSOFGEOI-OOOUBICS (decimal 456.) 
ECX=6E494714 (MSUCRIO0.__initenv) 
Local call from 871031 


SCII "H(F" 


global. 
ba l. 00871000 


jit BLFFFFFFFF) 
BLFFFFFFFF) 
CFFFFFFFF) 
(FFFFFFFF) 

EFDDaGat FFF) 
(FFFFFFFF) 


proc 


8 Tfi 
HOF hNF 


Fig. 1.26: OllyDbg : f1() commence 


Deux valeurs sont visibles sur la pile: 456 (0x1C8) et 123 (0x7B), et aussi les adresses 


des deux variables globales. 
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Suivons l'exécution jusqu'à la fin de f1(). Dans la fenétre en bas à gauche, nous 
voyons comment le résultat du calcul apparaît dans les variables globales: 


CPU - main thread, module global (Of x! 
q ^ 


SB4C24 08 
SB4424 84 
801498 
ØFAFC1 
8B4C24 10 
56 

887424 10 
91 


Top of stack LOBGSOFSD4 
ESI=9lobal. 90873384 


MOU ECX, DWORD PTR SS: CARG.2] 
MOV EAX, DWORD PTR SS: CARG. 1] 
LEA EDX, CECK+EAX] 

IMUL EAX, ECX 

MOV ECX, DWORD PTR SS:[ARG.4] 
PUSH ESI 

MOU ESI,DWORD PTR SS:LRRG.31 
MOU DWORD PTR DS: [ESIJ,EDX 
MOU DWORD PTR DS: CECK],EAX 
POP ESI 


9873388 


mc 


m 


CDAONDIO Mm mmmmmmmm 
ou 
GOOOOOC-O D AnD 


&1B 
t FFFFFFFF) 


it @(FFFFFFFF) 
it B(FFFFFFFF) 


BCFFFFFFFF) 


t rEFDDaBat FFF) 


BtFFFFFFFF) 


UCC 


PE, GE, G) 


Fig. 1.27: OllyDbg : l'exécution de f1() est terminée 
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Maintenant les valeurs des variables globales sont chargées dans des registres, 
prêtes à être passées a printf () (via la pile) : 


CPU - main thread, module global =1oj xi 


NT 

PUSH OFFSET 00873388 

68 24333700 | PUSH OFFSET 00873384 

68 CS818888 | PUSH 1C8 

6A 7B PUSH 7B 

ES CAFFFFFF | CALL 00871000 

Al 22229700 | MOU ERX,DWORD PTR DS: [873388] 
BØD FEESEIZA MOV ECX, DWORD PTR DS: [873384] 
5a PUSH EAX 


51 PUSH ECX 

68 99398709 | PUSH OFFSET 00873000 

FF15 992987@t CALL DWORD PTR DS: (<&MSVUCR1GG. printf >] 
8304 1C ADD ESP, 1C 

33008 XOR EAX, EAX 

BELL 

Stack [B030FSDSI=9lobal. 00871036 

EAX=0000DB18 (decimal 566888.) 


> 00871041 < 


ES a02B ØLFFFFFFFF) 
O(FFFFFFFF) 
O(FFFFFFFF) 
OLFFFFEFFF) 
7EFDDaBatFFF) 
BCFFFFFFFF) 


OAonmpoommmmmmmmmiz 


RETURN from glob. 
ASCII "phF'' 


a a a y 
GA Qa Qa 00 00 04 où an 


Fig. 1.28: OllyDbg : les adresses des variables globales sont passées a printf () 


Exemple avec des variables locales 
Modifions légérement notre exemple: 


Listing 1.103 : maintenant les variables sum et product sont locales 


void main() 


1 
int sum, product; // maintenant, les variables sont locales à la 
fonction 
f1(123, 456, &sum, &product); 
printf ("sum=%d, product=%d\n", sum, product); 
}; 


Le code de f1() ne va pas changer. Seul celui de main() va changer: 


Listing 1.104 : MSVC 2010 avec optimisation (/Ob0) 


_product$ = -8 ; size = 4 
_sum$ = -4 ; size = 4 
main PROC 
; Line 10 
sub esp, 8 
; Line 13 
lea eax, DWORD PTR _product$[esp+8] 
push eax 
lea ecx, DWORD PTR _sum$[esp+12] 


push ecx 
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push 456 ; 000001c8H 
push 123 ; 0000007bH 
call _f1 
: Line 14 
mov edx, DWORD PTR _product$[esp+24] 
mov eax, DWORD PTR _sum$[esp+24] 
push edx 
push eax 


push OFFSET $SG2803 
call DWORD PTR imp printf 


; Line 15 
xor eax, eax 
add esp, 36 


ret 0 
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Regardons á nouveau avec OllyDbg. Les adresses des variables locales dans la pile 
sont 0x2EF854 et 0x2EF858. Voyons comment elles sont poussées sur la pile: 


CPU - main thread, module local 


GGA61GI1E 
B 1 

83EC_08 
806424 

50 


804424 83 
‘8819960 


ganc1aacll + 33 
Stack [@G2EF84C 
EAX=0B2EF858 


LL 90A610008 
DWORD PTR LOCAL. 13 
DWORD PTR S LOCAL. 01l 
PUSH OF 
CALL <JMP, &MS 
XOR EAX, EAX 
2 


o 


Gococcococo 


GG2EF359 
aa2EFS98 
20068881 
(119121251217) 


96A6192B 
ES 09 


LastErr 


28008242 


local. 66A6182B 


: B(FFFFFFFF) 
BLFFFFFFFF) 
BLFFFFFFFF) 

t B(FFFFFFFF) 
it 7EFODGG@(FFF) 
: B(FFFFFFFF) 


66860868 ERROR SUCC 
(NO, NB, NE, A, NS, PO, Gl 


E 


E 
E,G) 


BO2EFSEC 


Fig. 1.29: OllyDbg : les adresses des variables locales sont poussées sur la pile 
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f1() commence. Jusqu'ici, il n'y a que des restes de données sur la pile en OX2EF854 
et 0x2EF858 : 


| CPU - main thread, module local (Ol x] 


C4 d 


8B4424 GC 


56 PUSH_ESI 
887424 08 MOV ESI, DWORD PTR SS: [ARG.1] 
SDacié LER ECX, [EDX+ESI] 
IMUL ESI,EDX 
MOU DWORD PTR DS: CEAXI,ECX 
MOU EAX, DWORD PTR SS: CARG. 4] 
MOU DWORD PTR DS: [EAXJ,ESI 


local. 60A61000 


ES GO2B S2bit BLFFFFFFFF) 
BLFFFFFFFF) 

: B(FFFFFFFF) 

: B(FFFFFFFF) 

t ?EFDDOBOLFFF) 
BtFFFFFFFF) 


8 Err 00000000 ERROR SUCCESS 
EFL 00000202 (NO,NB,NE,R,NS,PO, GE, G) 


SUB ESP,8 
RSA 


Qnowe 
UN NN O 


Stack DOUOUICS (decimal 456.) 
Local call from OR61838 


ODAONDIWO 


Fig. 1.30: OllyDbg : f1() commence 
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f1() se termine: 


| DS 
DWORD PTR 


96A61G1B 


@( FFFFFFFF) 
@( FFFFFFFF) 
@( FFFFFFFF) 
3 OLFFFFFFFE) 

B bit 7EFODG@G(FFF) 
002B 32bit B(FFFFFFFF) 


EE 
aaaaaics| “6 
C Ba2EFS5S xo. 


Top of stack toOzeFSSCI= 
ES1-0000DB1S (decimal Sedes. J 


¡DANRNDDIO m mmmmmmr mi 


Fig. 1.31: OllyDbg : f1() termine son exécution 


Nous trouvons maintenant 0xDB18 et 0x243 aux adresses 0x2EF854 et 0x2EF858. 
Ces valeurs sont les résultats de f1(). 


Conclusion 


f1() peut renvoyer des pointeurs sur n'importe quel emplacement en mémoire, si- 
tués n'importe oü. 


C'est par essence l'utilité des pointeurs. 


A propos, les references C++ fonctionnent exactement pareil. Voir à ce propos: 
(3.21.3 on page 721). 


1.16.2 Échanger les valeurs en entrée 


Ceci fait ce que l'on veut: 


#include <memory.h> 
#include <stdio.h> 


void swap bytes (unsigned char* first, unsigned char* second) 


{ 
unsigned char tmpl; 
unsigned char tmp2; 


tmpl-*first; 
tmp2=*second; 
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*first-tmp2; 
*second=tmpl; 


}; 
int main() 
{ 
// copier la chaîne dans la heap, afin de pouvoir la modifier 
char *s=strdup("string"); 
// échanger le 2ème et le 3ème caractères 
swap bytes (s+1, s+2); 
printf ("%s\n", s); 
}; 


Comme on le voit, les octets sont chargés dans la partie 8-bit basse de ECX et EBX 
en utilisant MOVZX (donc les parties hautes de ces registres vont être effacées) et 
ensuite les octets échangés sont récrits. 


Listing 1.105 : GCC 5.4 avec optimisation 


swap_bytes: 
push ebx 
mov edx, DWORD PTR [esp+8] 
mov eax, DWORD PTR [esp+12] 


movzx ecx, BYTE PTR [edx] 
movzx ebx, BYTE PTR [eax] 


mov BYTE PTR [edx], bl 
mov BYTE PTR [eax], cl 
pop ebx 

ret 


Les adresses des deux octets sont lues depuis les arguments et durant l'exécution 
de la fonction sont copiés dans EDX et EAX. 


Donc nous utilisons des pointeurs, il n'y a sans doute pas de meilleure facon de 
réaliser cette táche sans eux. 


1.17 Opérateur GOTO 


L'opérateur GOTO est en général considéré comme un anti-pattern, voir [Edgar Dijks- 
tra, Go To Statement Considered Harmful (1968)9?]. Néanmoins, il peut être utilisé 
raisonnablement, voir [Donald E. Knuth, Structured Programming with go to State- 
ments (1974)?9] ?!, 


Voici un exemple trés simple: 


#include <stdio.h> 


89http://yurichev.com/mirrors/Dijkstra68. pdf 
90http://yurichev.com/mirrors/KnuthStructuredProgrammingGoTo.pdf 
[Dennis Yurichev, C/C++ programming language notes] a aussi quelques exemples. 
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int main() 
1 
printf ("begin\n"); 
goto exit; 
printf ("skip me!\n"); 
exit: 
printf ("end\n"); 
}; 


Voici ce que nous obtenons avec MSVC 2012: 


Listing 1.106 : MSVC 2012 


$SG2934 DB 'begin', OaH, OOH 
$SG2936 DB ‘skip me!', OaH, 00H 
$SG2937 DB 'end', OaH, 00H 
main PROC 
push ebp 
mov ebp, esp 
push OFFSET $5G2934 ; 'begin' 
call _printf 
add esp, 4 
jmp SHORT $exit$3 
push OFFSET $5G2936 ; ‘skip me!' 
call _printf 
add esp, 4 
$exit$3: 
push OFFSET $5G2937 ; 'end' 
call _printf 
add esp, 4 
xor eax, eax 
pop ebp 
ret 0 
main  ENDP 


L'instruction goto a simplement été remplacée par une instruction JMP, qui a le 
méme effet: un saut inconditionnel à un autre endroit. Le second printf() peut 
seulement étre exécuté avec une intervention humaine, en utilisant un débogueur 
ou en modifiant le code. 
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Cela peut étre utile comme exercice simple de patching. Ouvrons l'exécutable géné- 
ré dans Hiew: 


Hiew: goto.exe 


'skip me!' 


Fig. 1.32: Hiew 
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Placez le curseur à l'adresse du JMP (0x410), pressez F3 (edit), pressez deux fois 
zéro, donc l'opcode devient EB 00 : 


Fig. 1.33: Hiew 


Le second octet de l'opcode de JMP indique l'offset relatif du saut, O signifie le point 
juste après l'instruction courante. 


Donc maintenant JMP n'évite plus le second printf(). 


Pressez F9 (save) et quittez. Maintenant, si nous lancons l'exécutable, nous verrons 
ceci: 


Listing 1.107 : Sortie de l'exécutable modifié 


C:\...>goto.exe 


begin 
skip me! 
end 


Le méme résultat peut étre obtenu en remplacant l'instruction JMP par 2 instructions 
NOP. 


NOP a un opcode de 0x90 et une longueur de 1 octet, donc nous en avons besoin de 
2 pour remplacer JMP (qui a une taille de 2 octets). 


1.17.1 Code mort 


Le second appel à printf() est aussi appelé «code mort» en terme de compilateur. 
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Cela signifie que le code ne sera jamais exécuté. Donc lorsque vous compilez cet 
exemple avec les optimisations, le compilateur supprime le «code mort », n'en lais- 
sant aucune trace: 


Listing 1.108 : MSVC 2012 avec optimisation 


$SG2981 DB 'begin', 0aH, OOH 
$5G2983 DB ‘skip me!', OaH, 00H 
$SG2984 DB 'end', OaH, 00H 
main PROC 

push OFFSET $SG2981 ; 'begin' 

call _ printf 

push OFFSET $5G2984 ; 'end' 
$exit$4: 

call _printf 

add esp, 8 

xor eax, eax 

ret 0 
main  ENDP 


Toutefois, le compilateur a oublié de supprimer la chaîne «skip me! ». 


1.17.2 Exercice 


Essayez d'obtenir le méme résultat en utilisant votre compilateur et votre débogueur 
favoris. 


1.18 Sauts conditionnels 


1.18.1 Exemple simple 


#include <stdio.h> 


void f signed (int a, int b) 


{ 
if (a>b) 
printf ("a>b\n"); 
if (a==b) 
printf ("a==b\n") ; 
if (a<b) 
printf ("a<b\n"); 
$; 
void f unsigned (unsigned int a, unsigned int b) 
1 
if (a>b) 
printf ("a>b\n"); 
if (a==b) 


printf ("a==b\n"); 
if (a<b) 
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printf ("a<b\n"); 
}; 


int main() 
{ 
f signed(1, 2); 
f unsigned(1, 2); 
return 0; 


}; 


x86 
x86 + MSVC 


Voici à quoi ressemble la fonction f. signed() : 


Listing 1.109 : MSVC 2010 sans optimisation 


_a$ = 8 
_b$ = 12 
f signed PROC 
push ebp 
mov ebp, esp 


mov eax, DWORD PTR a$[ebp] 
cmp eax, DWORD PTR _b$[ebp] 
jle SHORT $LN3@f_signed 
push OFFSET $SG737 ; 'a»b' 
call printf 
add esp, 4 
$LN3Gf signed: 
mov ecx, DWORD PTR a$[ebp] 
cmp ecx, DWORD PTR _b$[ebp] 
jne SHORT $LN2Gf signed 
push OFFSET $5G739 y 'a==b' 
call printf 
add esp, 4 
$LN2Gf signed: 
mov edx, DWORD PTR a$[ebp] 
cmp edx, DWORD PTR _b$[ebp] 
jge SHORT $LN4Gf signed 
push OFFSET $SG741 ; 'a«b' 
call printf 
add esp, 4 
$LNAQGf signed: 
pop ebp 
ret 0 
f signed ENDP 


La premiére instruction, JLE, représente Jump if Less or Equal (saut si inférieur ou 
égal). En d'autres mots, si le deuxieme opérande est plus grand ou égal au premier, 
le flux d'exécution est passé à l'adresse ou au label spécifié dans l'instruction. Si 
la condition ne déclenche pas le saut, car le second opérande est plus petit que le 
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premier, le flux d'exécution ne sera pas altéré et le premier printf () sera exécuté. 
Le second test est JNE : Jump if Not Equal (saut si non égal). Le flux d'exécution ne 
changera pas si les opérandes sont égaux. 


Le troisiéme test est JGE : Jump if Greater or Equal—saute si le premier opérande 
est supérieur ou égal au deuxiéme. Donc, si les trois sauts conditionnels sont ef- 
fectués, aucun des appels à printf() ne sera exécuté. Ceci est impossible sans 
intervention spéciale. Regardons maintenant la fonction f unsigned(). La fonction 
f unsigned() est la méme que f signed(), à la différence que les instructions JBE 
et JAE sont utilisées à la place de JLE et JGE, comme suit: 


Listing 1.110 : GCC 


_a$ = 8 ; size = 4 
_b$ = 12 ; size = 4 
_f_unsigned PROC 
push ebp 
mov ebp, esp 


mov eax, DWORD PTR a$[ebp] 
cmp eax, DWORD PTR _b$[ebp] 
jbe SHORT $LN3@f_unsigned 
push OFFSET $SG2761 ; 'a»b' 
call printf 
add esp, 4 

$LN3Gf unsigned: 
mov ecx, DWORD PTR a$[ebp] 
cmp ecx, DWORD PTR _b$[ebp] 
jne SHORT $LN2@f_unsigned 
push OFFSET $5G2763 y ‘a==b' 
call printf 
add esp, 4 

$LN2@f_unsigned: 
mov edx, DWORD PTR _a$[ebp] 
cmp edx, DWORD PTR _b$[ebp] 
jae SHORT $LN4@f_unsigned 
push OFFSET $SG2765 ; 'a«b' 
call printf 
add esp, 4 

$LNAQGf unsigned: 
pop ebp 
ret 0 

f unsigned ENDP 


Comme déjà mentionné, les instructions de branchement sont différentes: JBE— 
Jump if Below or Equal (saut si inférieur ou égal) et JAE—Jump if Above or Equal (saut 
si supérieur ou égal). Ces instructions (JA/JAE/JB/JBE) différent de JG/JGE/JL/JLE par 
le fait qu'elles travaillent avec des nombres non signés. 


C'est pourquoi si nous voyons que JG/JL sont utilisés à la place de JA/JB ou vice- 
versa, nous pouvons être presque sûr que les variables sont signées ou non signées, 
respectivement. Voici la fonction main(), oü presque rien n'est nouveau pour nous: 


Listing 1.111 : main() 
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_main 


_main 


PROC 
push 
mov 
push 
push 
call 
add 
push 
push 
call 
add 
xor 
pop 
ret 
ENDP 


ebp 

ebp, esp 
2 

1 

_f signed 
esp, 8 

2 

1 

_f unsigned 
esp, 8 
eax, eax 
ebp 

0 
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x86 + MSVC + OllyDbg 


Nous pouvons voir comment les flags sont mis en lancant cet exemple dans OllyDbg. 
Commençons par f unsigned(), qui utilise des entiers non signés. 


CMP est exécuté trois fois ici, mais avec les méme arguments, donc les flags sont les 
méme à chaque fois. 


Résultat de la premiére comparaison: 


CPU - main thread, module ex  - [nmi xl 
A1056 egi A 


PUSH EBP 

MOU EBP, ESP 

MOU EAX, DWORD PTR SS:CARG. 1] 17 MSUCR100. 6E445617 
CMP EAX, DWORD PTR SS: [ARG.2] x OS 
JBE SHORT 99111969 

8 18301900 |PUSH OFFSET 09113018 

FFIG SALAM CALL DWORD PTR Ds: [<8MSUCR100.printf>] 
MOU ECX, DWORD PTR SS: CARG. 1] JI 6018 
CMP ECX, DWORD PTR SS: CARG. 21 de 
JNE SHORT 001A107F | | QO1R105 
8 20301000 | PUSH OFFSET BaiR3820 c 

FF1S BO2O1Bei CALL DWORD PTR DS: [<eMSUCRIGO.printf>1 ; it OLFFFFFFFF] 
834 Øq ADD ESP,4 p 


, | it B(FFFFFFFF) 
8855 08 HOU EDX, DWORD PTR SS: LARG. 1] | Sobit O(FFFFFFFF) 


it 7EFODGGG( FFF) 
jit BC FFFFFFFF) 


RETURN from 


¿MO 
com 


RETURN from 


ASCII "phu" 


oco 
© © M 00 € 


Fig. 1.34: OllyDbg : f unsigned() : premier saut conditionnel 


Donc, les flags sont: C=1, P=1, A=1, Z=0, S=1, T=0, D=0, O=0. 
Ils sont nommés avec une seule lettre dans OllyDbg par concision. 


OllyDbg indique que le saut (JBE) va être suivi maintenant. En effet, si nous regar- 
dons dans le manuel d'Intel (12.1.4 on page 1315), nous pouvons lire que JBE est 
déclenchée si CF=1 ou ZF=1. La condition est vraie ici, donc le saut est effectué. 
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Le saut conditionnel suivant: 


main thread, module ex 


PUSH_EBP 

MOU EBP,ESP 

MOV EAX, DWORD PTR SS: [A 

CMP EAX, DWORD PTR SS: CAI 

JBE SHORT 0B1A1069 

PUSH OFFSET 60143018 (fs 
CALL DWORD PTR DS:L«&MSUCRI88.printf»l [Ln 


ADD ESP,4 
MOU ECX;DWORD PTR $S:CARG. 1] 
CMP ECX,DWORD PTR SS: [ARG. 2] 
JNE SHORT BB1A107F 
68 20201000 PUSH OFFSET BB1A3020 fc 
FF15 BaZ20180l CALL DWORD PTR DS: [<8MSUCRIG0.printf>1 [Uns po aaa 
. | 8304 04 ADD ESP, 4 : OLERERERFE) 
> b8B55 08 MOU EDX, DWORD PTR SS: CARG. 1] > t OLFEFFFFFF) 
E A P [ DWORD PTR R te 7 ARA r 
- - - - 7EFDDaaatFFF) 


BO1R186F e: 
j BBZE t @(FFFFFFFF) 


DOM mmm mmm M rmi 


Jump is taken : q - BL 7 
Dest-ex.DB1R187F BEFFEFEFFF 


RETURN from 
ASCII "pNU'" 


Fig. 1.35: OllyDbg : f unsigned() : second saut conditionnel 


OllyDbg indique que le saut JNZ va étre effectué maintenant. En effet, JNZ est dé- 
clenché si ZF=0 (Zero Flag). 
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Le troisieme saut conditionnel, JNB : 


- main thread, module ex 


is not taken 
961A1995 


SLONDOO 


JBE SHORT 96181869 

PUSH OFFSET 66103018 

CALL DWORD PTR DS: (<&MSUCR1GG. printf >] 
ADD ESP, 4 

MOV ECX,DWORD PTR SS: CARG. 1] 

CMP ECX, DWORD PTR SS:CARG.2] 

JNE SHORT 001A107F 

PUSH OFFSET 00143020 

CALL DWORD PTR DS: [<&MSUCR160. printf >] 
ADD ESP, 4 

MOU EDX, DWORD PTR SS: CARG. 1] 

CMP EDX, DWORD PTR SS: CARG.2] 

JAE SHORT 0011095 


PUSH OFFSET 99143928 
CALL DWORD PTR DS: (<&MSUCR1G0. printf >] 


TODO 


3 


(Uh 


mmm im mmmn ri 


it 
bit 7EFDDOBOLFFF) 
bit atFFFFFFFF) 


SUCCESS 


B,NE,BE,S,PE,L,LE 


RETURN from ex. 0 
ASCII "pNU" 


Fig. 1.36: OllyDbg : f unsigned() : troisième saut conditionnel 


Dans le manuel d'Intel (12.1.4 on page 1315) nous pouvons voir que JNB est déclen- 
ché si CF=0 (Carry Flag - flag de retenue). Ce qui n'est pas vrai dans notre cas, donc 
le troisiéme printf() sera exécuté. 
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Maintenant, regardons la fonction f signed(), qui fonctionne avec des entiers non 
signés. Les flags sont mis de la méme maniére: C=1, P=1, A=1, Z=0, S=1, T=0, 
D=0, O=0. Le premier saut conditionnel JLE est effectué: 


CPU - main thread, module ex (Ol x! 
a a ^ 


PUSH EBP 

MOU EBP,ESP 

MOY EAX, DWORD PTR SS: CARG.1] 

CMP ERX,DWORD PTR SS: CARG.2] 

JLE SHORT 98141919 

68 00201000 | PUSH OFFSET 66193000 

FF15 poanian) CALL DWORD PTR DS: (<&MSUCR1G6. printf >] 
MOY ECX, DWORD PTR SS: CARG.1] 

CMP ECX, DWORD PTR SS:CARG.2] 

JNE SHORT 961A162F 

PUSH OFFSET 60143008 

CALL DWORD PTR DS: (<&MSUCR1GG. printf >] 
ADD ESP,4 

MOY EDX, DWORD PTR SS: CARG.1] 

HP E 


mmmmmmmm| 


bit BtFFFFFFFF) 
bit &tFFFFFFFF) 
bit &tFFFFFFFF) 
bit DLFFFFFFFF) 
bit PEFDDGGG( FFF) 
bit atFFFFFFFF) 


)OHNND TO 


LastErr 88006000 ERROR S 


© © ©) 
m 


Tul 
CT 


¡DD 


© M 00 © 


Fig. 1.37: OllyDbg : f signed() : premier saut conditionnel 


Dans les manuels d'Intel (12.1.4 on page 1315) nous trouvons que cette instruction 
est déclenchée si ZF=1 ou SF+OF. SF«OF dans notre cas, donc le saut est effectué. 
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Le second saut conditionnel, JNZ, est effectué: si ZF=0 (Zero Flag) : 


CPU - main thread, module ex 


PUSH_EBP 

MOU EBP,ESP 

MOU EAX, DWORD PTR SS: [ARG. 1] 

CMP EAX, DWORD PTR SS:LRRG.21 

JLE SHORT 96181619 

PUSH OFFSET 00143000 

EM DWORD PTR DS: L4&MSUCR188.printf?1 


RDD ESP,4 
MOU ECX, DWORD PTR $S:CARG. 1] 
CMP ECX,DWORD PTR SS: CARG.2] 
JNE SHORT BB1A102F a 
PUSH OFFSET 99143988 g > it ØLFFFFFFFF) 
CALL DWORD PTR DS:LX&MSUCRIBB.print£?1 [kms fE : OLFFFFFFFE) 


ADD ESP, 4 : 
8B55 08 MOU EDX,DWORD PTR SS: [ARG. 1] ofan, 
G A DL) E E > 


L - T > TEFDDBBatFFF) 
it B(FFFFFFFF) 
r GBBBOBOB ERROR SUCCESS 
(NO, B, NE, BE, S, PE,L, LE) 


mmmmm m rm mig 


an 66 6 
an 68 aa 


nx 1122C|,$* |RETURN from ex. Øi 


SpA 


CU ANU ASCII "pNu" 


Fig. 1.38: OllyDbg : f signed() : second saut conditionnel 
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Le troisieme saut conditionnel, JGE, ne sera pas effectué car il ne l'est que si SF=OF, 
et ce n'est pas vrai dans notre cas: 


CPU - main thread, module ex  - [B8 xl 
E ^^ 


JLE SHORT 96181619 
8 29291000 |PUSH OFFSET 96183000 Cig 
5 Ba2aiBal BE PTR DS: [<2MSUCR10B0.printf>1 | bn 


MOU ECX,DWORD PTR SS: CARG.1] 
CHP ECX, DWORD PTR SS: CARG.2] 
JNE SHORT 9019102F 
PUSH OFFSET 0913008 fc 
CALL DWORD PTR DS: [<2MSUCR100.printf>1 [Lie 
ADD ESP,4 
MOU EDX, DWORD PTR SS: CARG.1] 
CMP EDX, DWORD PTR SS: CARG. 2] 
BLFFFFFFFF) 


JGE SHORT BBiR1B45 : 
PUSH OFFSET 80102010 fc OLFFFFFFFF) 
CALL DWORD PTR DS: [<2MSUCRIG0.printf>1 [Lis go | t OLFFFFFFFFÀ 


a( FFFFFFFF) 


DION mmmmmmmirm 


ADD E ; ; t "EFDDaaatFFF) 
2 G(FFFFFFFF) 


1 D A a 
FF FF FF FF|FF FF FF FF 
a 


1 RETURN from ex. Bl 


ASCII "pNur 


Fig. 1.39: OllyDbg : f signed() : troisiéme saut conditionnel 
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x86 + MSVC + Hiew 


Nous pouvons essayer de patcher l'exécutable afin que la fonction f unsigned() 
affiche toujours «a==b », quelque soient les valeurs en entrée. Voici à quoi ça res- 
semble dans Hiew: 


au 10 x! 
232 PE_.00401000|Hiew 8.02 (c)SEN | 


Fig. 1.40: Hiew: fonction f unsigned() 


Essentiellement, nous devons accomplir ces trois choses: 
* forcer le premier saut à toujours étre effectué; 
* forcer le second saut à n'étre jamais effectué; 
* forcer le troisiéme saut à toujours étre effectué. 


Nous devons donc diriger le déroulement du code pour toujours effectuer le second 
printf(), et afficher «a==b ». 


Trois instructions (ou octets) doivent étre modifiées: 
* Le premier saut devient un JMP, mais l'offset reste le méme. 


* Le second saut peut étre parfois suivi, mais dans chaque cas il sautera à l'ins- 
truction suivante, car nous avons mis l'offset à 0. 
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Dans cette instruction, l'offset est ajouté à l'adresse de l'instruction suivante. 
Donc si l'offset est O, le saut va transférer l'exécution à l'instruction suivante. 


* Letroisiéme saut est remplacé par JMP comme nous l'avons fait pour le premier, 
il sera donc toujours effectué. 
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Voici le code modifié: 


Fig. 1.41: Hiew: modifions la fonction f unsigned() 


Si nous oublions de modifier une de ces sauts conditionnels, plusieurs appels à 
printf() pourraient étre faits, alors que nous voulons qu'un seul soit exécuté. 


GCC sans optimisation 


GCC 4.4.1 sans optimisation produit presque le méme code, mais avec puts() (1.5.3 
on page 29) à la place de printf(). 


GCC avec optimisation 


Le lecteur attentif pourrait demander pourquoi exécuter CMP plusieurs fois, si les 
flags ont les mémes valeurs aprés l'exécution ? 


Peut-étre que l'optimiseur de de MSVC ne peut pas faire cela, mais celui de GCC 
4.8.1 peut aller plus loin: 


Listing 1.112 : GCC 4.8.1 f signed() 
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f_signed: 
mov eax, DWORD PTR [esp+8] 
cmp DWORD PTR [esp+4], eax 
jg .L6 
je .L7 
jge .L1 
mov DWORD PTR [esp+4], OFFSET FLAT:.LC2 ; "a<b" 
jmp puts 
.L6: 
mov DWORD PTR [esp+4], OFFSET FLAT:.LCO ; "a»b" 
jmp puts 
.L1: 
rep ret 
.L7: 
mov DWORD PTR [esp+4], OFFSET FLAT:.LC1 ; "a==b" 
jmp puts 


Nous voyons ici JMP puts au lieu de CALL puts / RETN. 
Ce genre de truc sera expliqué plus loin: 1.21.1 on page 205. 


Ce genre de code x86 est plutót rare. Il semble que MSVC 2012 ne puisse pas géné- 
rer un tel code. D'un autre cóté, les programmeurs en langage d'assemblage sont 
parfaitement conscients du fait que les instructions Jcc peuvent étre empilées. 


Donc si vous voyez ce genre d'empilement, il est trés probable que le code a été 
écrit à la main. 


La fonction f unsigned() n'est pas si esthétiquement courte: 


Listing 1.113 : GCC 4.8.1 f unsigned() 


f unsigned: 
push esi 
push ebx 
sub esp, 20 
mov esi, DWORD PTR [esp+32] 
mov ebx, DWORD PTR [esp+36] 
cmp esi, ebx 
ja .L13 
cmp esi, ebx ; cette instruction peut étre supprimée 
je .L14 
.L10: 
jb .L15 
add esp, 20 
pop ebx 
pop esi 
ret 
.L15: 
mov DWORD PTR [esp+32], OFFSET FLAT:.LC2 ; "a<b" 
add esp, 20 
pop ebx 
pop esi 
jmp puts 


.L13: 
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mov DWORD PTR [esp], OFFSET FLAT: .LCO ; "a>b" 
call puts 
cmp esi, ebx 
jne .L10 
.L14: 
mov DWORD PTR [esp+32], OFFSET FLAT:.LC1 ; "a==b" 
add esp, 20 
pop ebx 
pop esi 
jmp puts 


Néanmoins, il y a deux instructions CMP au lieu de trois. 
Donc les algorithmes d'optimisation de GCC 4.8.1 ne sont probablement pas encore 
parfaits. 


ARM 
ARM 32-bit 


avec optimisation Keil 6/2013 (Mode ARM) 


Listing 1.114 : avec optimisation Keil 6/2013 (Mode ARM) 


.text:000000B8 EXPORT f signed 

.text:000000B8 f signed ; CODE XREF: main+C 
.text:000000B8 70 40 2D E9 STMFD SP!, {R4-R6,LR} 
.text:000000BC 01 40 AO El MOV R4, R1 

.text:000000CO 04 00 50 El CMP RO, R4 

.text:000000C4 00 50 AO El MOV R5, RO 

.text:000000C8 1A OE 8F C2 ADRGT RO, aAB ; “a>b\n" 
.text:000000CC A1 18 00 CB BLGT . 2printf 

.text:000000D0 04 00 55 E1 CMP R5, R4 

.text:000000D4 67 OF 8F 02 ADREQ RO, aAB 0 ; "a==bin" 
.text:000000D8 9E 18 00 OB BLEQ . 2printf 

.text:000000DC 04 00 55 E1 CMP R5, R4 

.text:000000E0 70 80 BD A8 LDMGEFD SP!, {R4-R6,PC} 
.text:000000E4 70 40 BD E8 LDMFD SP!, {R4-R6,LR} 

. text: Q000000E8 19 OE 8F E2 ADR RO, aAB 1 > "a<b\n" 
.text:000000EC 99 18 00 EA B . 2printf 

.text:000000EC ; End of function f signed 


Beaucoup d'instructions en mode ARM ne peuvent étre exécutées que lorsque cer- 
tains flags sont mis. E.g, ceci est souvent utilisé lorsque l'on compare les nombres 


Par exemple, l'instruction ADD est en fait appelée ADDAL en interne, où AL signifie 
Always, i.e., toujours exécuter. Les prédicats sont encodés dans les 4 bits du haut 
des instructions ARM 32-bit. (condition field). L'instruction de saut inconditionnel B 
est en fait conditionnelle et encodée comme toutes les autres instructions de saut 
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conditionnel, mais a AL dans le champ de condition, et s'exécute toujours (Always), 
ignorants les flags. 


L'instruction ADRGT fonctionne comme ADR mais ne s'exécute que dans le cas ou 
l'instruction CMP précédente a trouvé un des nombres plus grand que l'autre, en 
comparant les deux (Greater Than). 


L'instruction BLGT se comporte exactement comme BL et n'est effectuée que si le 
résultat de la comparaison était Greater Than (plus grand). ADRGT écrit un pointeur 
sur la chaine a>b\n dans RO et BLGT appelle printf(). Donc, les instructions suf- 
fixées par -GT ne sont exécutées que si la valeur dans RO (qui est a) est plus grande 
que la valeur dans R4 (qui est b). 


En avançant, nous voyons les instructions ADREQ et BLEQ. Elles se comportent comme 
ADR et BL, mais ne sont exécutées que si les opérandes étaient égaux lors de la der- 
niére comparaison. Un autre CMP se trouve avant elles (car l'exécution de printf() 
pourrait avoir modifiée les flags). 


Ensuite nous voyons LDMGEFD, cette instruction fonctionne comme LDMFD??, mais 
n'est exécutée que si l'une des valeurs est supérieure ou égale à l'autre (Greater or 
Equal). 

L'instruction LDMGEFD SP! , {R4-R6,PC} se comporte comme une fonction épilogue, 
mais elle ne sera exécutée que si a >= b, et seulement lorsque l'exécution de la 
fonction se terminera. 


Mais si cette condition n'est pas satisfaite, i.e., a < b, alors le flux d'exécution continue 
à l'instruction suivante, «LDMFD SP!, {R4-R6,LR}», qui est aussi un épilogue de la 
fonction. Cette instruction ne restaure pas seulement l'état des registres R4-R6, mais 
aussi LR au lieu de PC, donc il ne retourne pas de la fonction. Les deux derniéres ins- 
tructions appellent printf() avec la chaîne «a<b\n» comme unique argument. Nous 
avons déjà examiné un saut inconditionnel à la fonction printf () au lieu d'un appel 
avec retour dans «printf() avec plusieurs arguments» section (1.11.2 on page 75). 


f unsigned est trés similaire, à part les instructions ADRHI, BLHI, et LDMCSFD utili- 
sées ici, ces prédicats (HI = Unsigned higher, CS = Carry Set (greater than or equal)) 
sont analogues à ceux examinés avant, mais pour des valeurs non signées. 


Il n'y a pas grand chose de nouveau pour nous dans la fonction main() : 


Listing 1.115 : main() 


.text:00000128 EXPORT main 
.text:00000128 main 

.text:00000128 10 40 2D E9 STMFD SP!, {R4,LR} 
.text:0000012C 02 10 AO E3 MOV R1, 42 
.text:00000130 01 00 AO E3 MOV RO, £1 
.text:00000134 DF FF FF EB BL f signed 
.text:00000138 02 10 AO E3 MOV Rl, #2 

. text: 0000013C 01 00 AO E3 MOV RO, #1 
.text:00000140 EA FF FF EB BL f_unsigned 
.text:00000144 00 00 AO E3 MOV RO, #0 
.text:00000148 10 80 BD E8 LDMFD SP!, {R4,PC} 
.text:00000148 ; End of function main 


921 DMFD 
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C'est ainsi que vous pouvez vous débarrasser des sauts conditionnels en mode ARM. 


Pourquoi est-ce que c'est si utile? Lire ici: 2.4.1 on page 589. 


Il n'y a pas de telle caractéristique en x86, exceptée l'instruction CMOVcc, qui est 
comme un MOV, mais effectuée seulement lorsque certains flags sont mis, en général 
mis par CMP. 


avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.116 : avec optimisation Keil 6/2013 (Mode Thumb) 


.text:00000072 f signed ; CODE XREF: main+6 
.text:00000072 70 B5 PUSH {R4-R6,LR} 

. text: 00000074 OC 00 MOVS R4, R1 

. text: 00000076 05 00 MOVS R5, RO 

. text: 00000078 A0 42 CMP RO, R4 

.text:0000007A 02 DD BLE loc_82 

.text:0000007C A4 AO ADR RO, aAB ; “a>b\n" 
.text:0000007E 06 FO B7 F8 BL _ 2printf 

.text:00000082 

.text:00000082 loc 82 ; CODE XREF: f signed+8 
.text:00000082 A5 42 CMP R5, R4 

.text:00000084 02 D1 BNE loc 8C 

.text:00000086 A4 AO ADR RO, aAB 0 ; "a==b\n" 
.text:00000088 06 FO B2 F8 BL _ 2printf 

.text:0000008C 

.text:0000008C loc 8C ; CODE XREF: f signed+12 
.text:0000008C A5 42 CMP R5, R4 

.text:0000008E 02 DA BGE locret 96 

.text:00000090 A3 AO ADR RO, aAB 1 ; "a<bin" 
.text:00000092 06 FO AD F8 BL _ 2printf 

.text:00000096 

.text:00000096 locret 96 ; CODE XREF: f signed+1C 
.text:00000096 70 BD POP {R4-R6,PC} 

. text: 00000096 ; End of function f signed 


En mode Thumb, seules les instructions B peuvent étre complétées par un condition 
codes, (code de condition) donc le code Thumb parait plus ordinaire. 


BLE est un saut conditionnel normal Less than or Equal (inférieur ou égal), BNE—Not 
Equal (non égal), BGE—Greater than or Equal (supérieur ou égal). 


f unsigned est similaire, seules d'autres instructions sont utilisées pour travailler 
avec des valeurs non-signées: BLS (Unsigned lower or same non signée, inférieur ou 
égal) et BCS (Carry Set (Greater than or equal) supérieur ou égal). 


ARM64: GCC (Linaro) 4.9 avec optimisation 


Listing 1.117 : f signed() 


f signed: 
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; W=a, Wl=b 

cmp wO, wl 

bgt .L19 ; Branch if Greater Than 

; branchement is supérieur (a»b) 
beq .L20 ; Branch if Equal 
; branchement si égal (a--b) 
bge .L15 ; Branch if Greater than or Equal 
; branchement si supérieur ou égal (a>=b) (impossible ici) 

; a«b 

adrp x0, .LC11 ; "a«b" 

add x0, x0, :1012:.LC11 

b puts 
.L19: 

adrp x0, .LC9 ; "a»b" 

add x0, x0, :1012:.LC9 

b puts 
.L15: ; impossible d'arriver ici 

ret 
.L20: 

adrp x0, .LC10 ; "a==b" 

add x0, x0, :lo12:.LC10 

b puts 

Listing 1.118 : f unsigned() 

f unsigned: 

stp x29, x30, [sp, -48]! 
; W=a, Wl=b 

cmp wO, wl 

add x29, sp, 0 

str x19, [sp,16] 

mov w19, w0 

bhi .L25 ; Branch if HIgher 

; branchement si supérieur (a»b) 
cmp w19, wl 
beq .L26 ; Branch if Equal 
; branchement si égal (a--b) 

.L23: 

bcc . L27 ; Branch if Carry Clear 


; branchement si le flag de retenue est à zéro (si 


inférieur) (a<b) 
; épilogue de la fonction, impossible d'arriver ici 
ldr x19, [sp,16] 


ldp x29, x30, [sp], 48 
ret 
. L27: 
ldr x19, [sp,16] 
adrp x0, .LC11 ; "a«b" 
ldp x29, x30, [sp], 48 
add x0, x0, :lo12:.LC11 
b puts 
.L25: 
adrp x0, .LC9 ; "a»b" 


str x1, [x29,40] 
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add x0, x0, :lo12:.LC9 

bl puts 

ldr x1, [x29,40] 

cmp w19, wl 

bne .L23 ; Branch if Not Equal 

; branchement si non égal 

.L26: 

ldr x19, [sp,16] 

adrp x0, .LC10 ; "a--b" 

ldp x29, x30, [sp], 48 

add x0, x0, :lo12:.LC10 

b puts 


Les commentaires ont été ajoutés par l'auteur de ce livre. Ce qui frappe ici, c'est que 
le compilateur n'est pas au courant que certaines conditions ne sont pas possible 
du tout, donc il y a du code mort par endroit, qui ne sera jamais exécuté. 


Exercice 


Essayez d'optimiser manuellement la taille de ces fonctions, en supprimant les ins- 
tructions redondantes, sans en ajouter de nouvelles. 


MIPS 


Une des caractéristiques distinctives de MIPS est l'absence de flag. Apparemment, 
cela a été fait pour simplifier l'analyse des dépendances de données. 


Il y a des instructions similaires à SETcc en x86: SLT («Set on Less Than » : mettre si 
plus petit que, version signée) et SLTU (version non signée). Ces instructions mettent 
le registre de destination à 1 si la condition est vraie ou à 0 autrement. 


Le registre de destination est ensuite testé avec BEQ («Branch on Equal» branche- 
ment si égal) ou BNE («Branch on Not Equal» branchement si non égal) et un saut 
peut survenir. Donc, cette paire d'instructions doit étre utilisée en MIPS pour compa- 
rer et effectuer un branchement. Essayons avec la version signée de notre fonction: 


Listing 1.119 : GCC 4.4.5 sans optimisation (IDA) 


.text:00000000 f signed: # CODE XREF: main+18 
.text:00000000 


.text:00000000 var 10 - -0x10 

.text:00000000 var 8 = -8 

.text:00000000 var 4 = -4 

.text:00000000 arg 0 = 0 

.text:00000000 arg 4 = 4 

. text: 00000000 

.text:00000000 addiu $sp, -0x20 
.text:00000004 SW $ra, Ox20+var 4($sp) 
. text: 00000008 Sw $fp, Ox20+var 8($sp) 
.text:0000000C move $fp, $sp 
.text:00000010 la $gp, gnu local gp 


.text:00000018 SW $gp, 0x20+var_10($sp) 
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; stocker les valeurs en entrée sur 


.text:0000001C SW 
. text : 00000020 SW 
; reload them. 
.text:00000024 lw 
.text:00000028 lw 
; $vO-b 

; $v1-a 

.text:0000002C or 


$a0, 
gal, 


$v1, 
$v0, 


$at, 


la pile locale: 
0x20+arg_0($fp) 
0x20+arg 4($fp) 


0x20+arg_0($fp) 
0x20+arg 4($fp) 


$zero ; NOP 


; ceci est une pseudo-instructions. en fait, c'est "slt $v0,$v0,$v1" ici. 
; donc $v0 sera mis à 1 si $v0<$v1 (b«a) ou à O autrement: 


.text:00000030 slt 


$v0, 


$v1 


; Saut en loc 5c, si la condition n'est pas vraie. 
; ceci est une pseudo-instruction. en fait, c'est "beq $vO,$zero,loc 5c" ici: 


.text:00000034 beqz 
; afficher "a>b" et terminer 
.text:00000038 or 
.text:0000003C lui 
.text:00000040 addiu 
.text:00000044 lw 
.text:00000048 or 
.text:0000004C move 
.text:00000050 jalr 
.text:00000054 or 
.text:00000058 lw 

. text: 0000005C 
.text:0000005C loc 5C: 
.text:0000005C lw 

. text: 00000060 lw 

. text: 00000064 or 


$v0, 


$at, 
$v0, 
$a0, 
$v0, 
$at, 
$t9, 
$t9 

gat, 
$9p, 


$v1, 
$v0, 
$at, 


loc 5C 


$zero ; slot de délai de branchement, NOP 
(unk 230 >> 16) + “a>b" 

$v0, (unk 230 € OXFFFF) 4 "a»b" 

(puts € OxFFFF) ($gp) 

$zero ; NOP 

$v0 


$zero ; slot de délai de branchement, NOP 
Ox20+var 10($fp) 


# CODE XREF: f_signed+34 
0x20+arg_0($fp) 
0x20+arg 4($fp) 
$zero ; NOP 


; tester si a==b, sauter en loc_90 si ce n'est pas vral: 


. text: 00000068 
. text: 0000006C 


bne 
or 


; la condition est vraie, donc 
.text:00000070 lui 
.text:00000074 addiu 
.text:00000078 lw 

. text: 0000007C or 

. text : 00000080 move 
. text: 00000084 jalr 
. text: 00000088 or 

. text: 0000008C lw 

. text: 00000090 

. text: 00000090 loc 90: 

. text: 00000090 lw 

. text : 00000094 lw 

. text: 00000098 or 


$v1, 
$at, 


afficher 


$v0, 
$a0, 
$v0, 
$at, 
$t9, 
$t9 

gat, 
$gp, 


$v1, 
$v0, 
$at, 


$vO, loc 90 

$zero ; slot de délai de branchement, NOP 
"a==b" et terminer: 

(aAB >> 16) # "a==b" 
$v0, (aAB & OxFFFF) 
(puts € OxFFFF) ($gp) 
$zero ; NOP 

$v0 


# “a==b" 


$zero ; slot de délai de branchement, NOP 
Ox20+var 10($fp) 


# CODE XREF: f_signed+68 
0x20+arg_0($fp) 
Ox20+arg 4($fp) 
$zero ; NOP 


; tester si $vl1<$v0 (a<b), mettre $v0 à 1 si la condition est vraie: 


. text: 0000009C slt 


$v0, 


$vl, $v0 


; Si la condition n'est pas vraie (i.e., $v0--0), sauter en loc c8: 


.text:000000A0 beqz 
.text:000000A4 or 
; la condition est vraie, 


$v0, 
$at, 


afficher 


loc C8 
$zero ; slot de délai de branchement, NOP 
"a<b" et terminer 
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.text:000000A8 lui $vO, (aAB 0 >> 16) # "a<b” 

.text:000000AC addiu $a0, $v0, (aAB_0 € OxFFFF) # "a<b" 
.text:000000B0 lw $vO, (puts € OxFFFF) ($gp) 

.text:000000B4 or $at, $zero ; NOP 

.text:000000B8 move $t9, $v0 

.text:000000BC jalr $t9 

.text:000000CO or $at, $zero ; slot de délai de branchement, NOP 
. text: 00000004 lw $gp, 0x20+var_10($fp) 


. text: 000000C8 
; toutes les 3 conditions étaient fausses, donc simplement terminer: 


.text:000000C8 loc C8: # CODE XREF: 
f signed+A0 
.text:000000C8 move $sp, $fp 
.text:000000CC lw $ra, Ox20+var 4($sp) 
. text: 000000D0 lw $fp, Ox20+var 8($sp) 
. text: 000000D4 addiu  $sp, 0x20 
. text: 000000D8 jr $ra 
.text:000000DC or $at, $zero ; slot de délai de branchement, NOP 


.text:000000DC # Fin de la fonction f signed 


SLT REGO, REGO, REGI est réduit par IDA à sa forme plus courte: 
SLT REGO, REGI. 


Nous voyons également ici la pseudo instruction BEQZ («Branch if Equal to Zero» 
branchement si égal à zéro), 
qui est en fait BEQ REG, $ZERO, LABEL 


La version non signée est la méme, mais SLTU (version non signée, d'oü le «U» de 
unsigned) est utilisée au lieu de SLT : 


Listing 1.120 : GCC 4.4.5 sans optimisation (IDA) 


.text:000000E0 f unsigned: # CODE XREF: main+28 
.text:000000E0 


.text:000000E0 var 10 = -0x10 

.text:000000E0 var 8 = -8 

.text:000000E0 var 4 = -4 

.text:000000E0 arg 0 = 0 

.text:000000E0 arg 4 = 4 

.text:000000E0 

.text:000000E0 addiu $sp, -0x20 
.text:000000E4 SW $ra, Ox20+var 4($sp) 
. text: 000000E8 SW $fp, Ox20+var 8($sp) 
.text:000000EC move $fp, $sp 
.text:000000F0 la $gp, gnu local gp 
. text: 000000F8 SW $gp, Ox20+var 10($sp) 
.text:000000FC Sw $a0, Ox20+arg O($fp) 
.text:00000100 SW $al, 0x20+arg_4($fp) 
.text:00000104 lw $vl, 0x20+arg_0($fp) 
.text:00000108 lw $v0, Ox20+arg 4($fp) 
. text: 0000010C or gat, $zero 

. text: 00000110 sltu $vO, $v1 
.text:00000114 begz $vO, loc 13C 


.text:00000118 or $at, $zero 
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.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


0000011C lui $v0, 
00000120 addiu $a0, 
00000124 lw $v0, 
00000128 or $at, 
0000012C move $t9, 
00000130 jalr $t9 
00000134 or $at, 
:00000138 lw $gp, 
0000013C 

0000013C loc_13C: 

0000013C lw $vl, 
00000140 lw $v0, 
00000144 or $at, 
00000148 bne $v1, 
0000014C or gat, 
00000150 lui $v0, 
00000154 addiu $a0, 
00000158 lw $v0, 
0000015C or $at, 
00000160 move $t9, 
00000164 jalr $t9 
00000168 or $at, 
:0000016C lw $gp, 
00000170 

00000170 loc 170: 

00000170 lw $v1, 
00000174 lw $v0, 
00000178 or $at, 
0000017C sltu $v0, 
00000180 beqz $v0, 
00000184 or gat, 
00000188 lui $v0, 
0000018C addiu $a0, 
:00000190 lw $v0, 
00000194 or gat, 
00000198 move $t9, 
0000019C jalr $t9 
00000140 or $at, 
000001A4 lw $gp, 
000001A8 

000001A8 loc 1A8: 

000001A8 move $sp, 
000001AC lw $ra, 
000001B0 lw $fp, 
000001B4 addiu $sp, 
000001B8 jr $ra 
000001BC or gat, 
000001BC # End of function f 


(unk 230 >> 16) 

$vO, (unk 230 € OxFFFF) 
(puts € OxFFFF) ($gp) 
$zero 

$v0 


$zero 
0x20+var_10($fp) 


# CODE XREF: f unsigned+34 
0x20+arg_0($fp) 
0x20+arg 4($fp) 
$zero 
$vO, loc 170 
$zero 
(aAB >> 16) # "a==b" 
$vO, (aAB € OxFFFF) 4 
(puts € OxFFFF) ($gp) 
$zero 
$v0 


ta==p" 


$zero 
0x20+var_10($fp) 


# CODE XREF: f unsigned+68 
0x20+arg_0($fp) 
0x20+arg 4($fp) 
$zero 
$vl, $v0 
loc_1A8 
$zero 
(aAB_0 >> 16) # “a<b" 
$vO, (aAB 0 € OxFFFF) + 
(puts € OxFFFF) ($gp) 
$zero 
$v0 


"acp" 


$zero 
Ox20+var 10($fp) 


# CODE XREF: f unsigned+A0 
$fp 
Ox20+var 4($sp) 
Ox20+var 8($sp) 
0x20 


$zero 
unsigned 


1.18.2 Calcul de valeur absolue 


Une fonction simple: 
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int my abs (int i) 
1 
if (i«0) 
return -i; 
else 
return i; 


MSVC avec optimisation 
Ceci est le code généré habituellement: 


Listing 1.121 : MSVC 2012 x64 avec optimisation 


ig = 8 
my abs PROC 
; ECX = valeur en entrée 
test ecx, ecx 
; tester le signe de la valeur en entrée 
; sauter l'instruction NEG si le signe est positif 


jns SHORT $LN2Gmy abs 
; inverser la valeur 
neg ecx 


$LN2Gmy abs: 
; copier le résultat dans EAX: 


mov eax, ecx 
ret 0 
my abs ENDP 


GCC 4.9 génére en gros le méme code: 


avec optimisation Keil 6/2013 : Mode Thumb 


Listing 1.122 : avec optimisation Keil 6/2013 : Mode Thumb 


my abs PROC 

CMP r0,#0 
; est-ce que la valeur en entrée est égale ou plus grande que zéro? 
; Si oui, sauter l'instruction RSBS 


BGE [L0.6| 
; soustraire la valeur en entrée de 0: 
RSBS r0,r0,#0 
|LO.6| 
lr 
ENDP 


Il manque une instruction de négation en ARM, donc le compilateur Keil utilise l'ins- 
truction «Reverse Subtract », qui soustrait la valeur du registre de l'opérande. 
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avec optimisation Keil 6/2013 : Mode ARM 


Il est possible d'ajouter un code de condition á certaines instructions en mode ARM, 
c'est donc ce que fait le compilateur Keil: 


Listing 1.123 : avec optimisation Keil 6/2013 : Mode ARM 


my abs PROC 

CMP ro,*0 
; exécuter l'instruction "Reverse Subtract" seulement si la valeur en entrée 
; est plus petite que 0: 

RSBLT r0,r0,#0 

BX lr 

ENDP 


Maintenant, il n'y a plus de saut conditionnel et c'est mieux: 2.4.1 on page 589. 


GCC 4.9 sans optimisation (ARM64) 
ARM64 possède l'instruction NEG pour effectuer la négation: 


Listing 1.124 : GCC 4.9 avec optimisation (ARM64) 


my abs: 

sub sp, sp, £16 

str w0, [sp,12] 

ldr w0, [sp,12] 
; comparer la valeur en entrée avec le contenu du registre WZR 
; (qui contient toujours zéro) 


cmp w0, wzr 
bge .L2 
ldr w0, [sp,12] 
neg wO, wO 
b .L3 
.L2: 
ldr w0, [sp,12] 
.L3: 
add sp, sp, 16 
ret 
MIPS 
Listing 1.125 : GCC 4.4.5 avec optimisation (IDA) 
my abs: 


; Saut si $a0«0: 
bltz $a0, locret 10 
; simplement renvoyer la valeur en entrée ($a0) dans $v0: 


move $v0, $a0 
jr $ra 
or $at, $zero ; slot de délai de branchement, NOP 


locret_10: 
; prendre l'opposée de la valeur entrée et la stocker dans $v0: 


188 
jr $ra | 


; ceci est une pseudo-instruction. En fait, ceci est "subu $v0,$zero,$a0" 
($v0z0-$a0) 
negu $v0, $a0 | 


Nous voyons ici une nouvelle instruction: BLTZ («Branch if Less Than Zero » branche- 
ment si plus petit que zéro). 


Il y a aussila pseudo-instruction NEGU, qui effectue une soustraction à zéro. Le suffixe 
«U» dans les deux instructions SUBU et NEGU indique qu'aucune exception ne sera 
levée en cas de débordement de la taille d'un entier. 


Version sans branchement? 


Vous pouvez aussi avoir une version sans branchement de ce code. Ceci sera revu 
plus tard: 3.16 on page 664. 


1.18.3 Opérateur conditionnel ternaire 


L'opérateur conditionnel ternaire en C/C++ a la syntaxe suivante: 


expression ? expression : expression 


Voici un exemple: 


const char* f (int a) 


1 


return a==10 ? "it is ten" : "it is not ten"; 


x86 


Les vieux compilateurs et ceux sans optimisation générent du code assembleur 
comme si des instructions if/else avaient été utilisées: 


Listing 1.126 : MSVC 2008 sans optimisation 


$SG746 DB ‘it is ten', 00H 
$SG747 DB ‘it is not ten', OOH 
tv65 = -4 ; ceci sera utilisé comme variable temporaire 
_a$ = 8 
_f PROC 
push ebp 
mov ebp, esp 
push ecx 
; comparer la valeur en entrée avec 10 
cmp DWORD PTR a$[ebp], 10 
; sauter en $LN3Gf si non égal 
jne SHORT $LN3@f 
; stocker le pointeur sur la chaîne dans la variable temporaire: 
mov DWORD PTR tv65[ebp], OFFSET $SG746 ; ‘it is ten' 
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; sauter à la sortie 


jmp SHORT $LN4@f 
$LN3@f : 
; stocker le pointeur sur la chaîne dans la variable temporaire: 

mov DWORD PTR tv65[ebp], OFFSET $SG747 ; 'it is not ten' 
$LN4@f : 


; ceci est la sortie. 
; copier le pointeur sur la chaine depuis la variable temporaire dans EAX. 


mov eax, DWORD PTR tv65[ebp] 
mov esp, ebp 
pop ebp 
ret 0 
f ENDP 


Listing 1.127 : MSVC 2008 avec optimisation 


$SG792 DB ‘it is ten', 00H 
$SG793 DB ‘it is not ten', OOH 
_a$ = 8 ; taille = 4 
_f PROC 
; comparer la valeur en entrée avec 10 
cmp DWORD PTR a$[esp-4], 10 
mov eax, OFFSET $SG792 ; ‘it is ten' 
; sauter en $LN4Gf si égal 
je SHORT $LN4@f 
mov eax, OFFSET $SG793 ; ‘it is not ten' 
$LN4@f : 
ret 0 
f ENDP 


Les nouveaux compilateurs sont plus concis: 


Listing 1.128 : MSVC 2012 x64 avec optimisation 


$5G1355 DB 'it is ten', 00H 
$5G1356 DB 'it is not ten', 00H 
a$ = 8 
f PROC 
; charger les pointeurs sur les deux chaînes 
lea rdx, OFFSET FLAT:$SG1355 ; ‘it is ten' 
lea rax, OFFSET FLAT:$SG1356 ; ‘it is not ten' 
; comparer la valeur en entrée avec 10 
cmp ecx, 10 


; Si égal, copier la valeur dans RDX ("it is ten") 
; si non, ne rien faire. le pointeur sur la chaíne 
; "it is not ten" est encore dans RAX à ce stade. 
cmove rax, rdx 
ret 0 
f ENDP 


GCC 4.8 avec optimisation pour x86 utilise également l'instruction CMOVcc, tandis 
que GCC 4.8 sans optimisation utilise des sauts conditionnels. 
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ARM 
Keil avec optimisation pour le mode ARM utilise les instructions conditionnelles ADRcc : 


Listing 1.129 : avec optimisation Keil 6/2013 (Mode ARM) 


f PROC 
; comparer la valeur en entrée avec 10 
CMP ro,*0xa 
; Si le résultat de la comparaison est égal (EQual), copier le pointeur sur 
la chaîne 
; "it is ten" dans RO 
ADREQ r0,|L0.16| ; "it is ten" 


; Si le résultat de la comparaison est non égal (Not EQual), copier le 
pointeur sur la chaíne 
; "it is not ten" dans RO 


ADRNE r0,|L0.28| ; "it is not ten" 
BX lr 
ENDP 
[L0.16| 
DCB "it is ten",0 
[L0.28| 
DCB "it is not ten",0 


Sans intervention manuelle, les deux instructions ADREQ et ADRNE ne peuvent étre 
exécutées lors de la méme exécution. 


Keil avec optimisation pour le mode Thumb à besoin d'utiliser des instructions de 
saut conditionnel, puisqu'il n'y a pas d'instruction qui supporte le flag conditionnel. 


Listing 1.130 : avec optimisation Keil 6/2013 (Mode Thumb) 


f PROC 
; comparer la valeur entrée avec 10 
CMP ro,*0xa 
; sauter en |L0.8| si égal (EQual) 
BEQ [L0.8| 
ADR r0,|L0.12| ; "it is not ten" 
BX lr 
[L0.8| 
ADR r0,|L0.28| ; "it is ten" 
BX lr 
ENDP 
[L0.12| 
DCB "it is not ten",0 
[L0.28| 
DCB "it is ten",0 
ARM64 


GCC (Linaro) 4.9 avec optimisation pour ARM64 utilise aussi des sauts conditionnels: 
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Listing 1.131 : GCC (Linaro) 4.9 avec optimisation 


f: 
cmp x0, 10 
beq .L3 ; branchement si égal 
adrp x0, .LC1 ; "it is ten" 
add x0, x0, :1012:.LC1 
ret 
.L3: 
adrp x0, .LCO ; "it is not ten" 
add x0, x0, :1012:.LCO0 
ret 
.LC0: 
.string "it is ten" 
.LC1: 


.string "it is not ten" 


C'est parce qu’ARM64 n'a pas d'instruction de chargement simple avec le flag condi- 
tionnel comme ADRcc en ARM 32-bit ou CMOVcc en x86. 


Il a toutefois l'instruction «Conditional SELect » (CSEL)[ARM Architecture Reference 
Manual, ARMv8, for ARMv8-A architecture profile, (2013)p390, C5.5], mais GCC 4.9 
ne semble pas assez malin pour l'utiliser dans un tel morceau de code. 


MIPS 
Malheureusement, GCC 4.4.5 pour MIPS n'est pas trés malin non plus: 


Listing 1.132 : GCC 4.4.5 avec optimisation (résultat en sortie de l'assembleur) 
$LCO: 


“ascii "it is not ten\000" 


$LC1: 

„ascii "it is ten\000" 
f: 

li $2,10 # Oxa 
; comparer $a0 et 10, sauter si égal: 

beq $4,$2,$L2 


nop ; slot de délai de branchement 


; charger l'adresse de la chaîne "it is not ten" dans $v0 et sortir: 


lui $2,%hi($LCO) 
j $31 
addiu $2,$2,%lo($LCO) 
$L2: 
; charger l'adresse de la chaine "it is ten" dans $v0 et sortir: 


lui $2,%hi($LC1) 
j $31 
addiu  $2,$2,%lo($LC1) 


Récrivons-le à l'aide d'unif/else 
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const char* f (int a) 


1 
if (a==10) 
return "it is ten"; 
else 
return "it is not ten"; 
F 


Curieusement, GCC 4.8 avec l'optimisation a pú utiliser CMOVcc dans ce cas: 


Listing 1.133 : GCC 4.8 avec optimisation 


.LC0: 
.string "it is ten" 
LCL: 
.string "it is not ten" 
f: 
.LFBO: 
; comparer la valeur en entrée avec 10 
cmp DWORD PTR [esp+4], 10 
mov edx, OFFSET FLAT:.LC1 ; "it is not ten" 
mov eax, OFFSET FLAT:.LCO ; "it is ten" 
; si le résultat de la comparaison est Not Equal, copier la valeur de EDX 
dans EAX 


; sinon, ne rien faire 
cmovne eax, edx 
ret 


Keil avec optimisation génére un code identique à listado.1.129. 


Mais MSVC 2012 avec optimisation n'est pas (encore) si bon. 


Conclusion 


Pourquoi est-ce que les compilateurs qui optimisent essayent de se débarrasser des 
sauts conditionnels? Voir à ce propos: 2.4.1 on page 589. 


1.18.4 Trouver les valeurs minimale et maximale 
32-bit 


int my max(int a, int b) 
1 
if (a»b) 

return a; 
else 
return b; 


}; 


int my min(int a, int b) 
1 
if (a«b) 


return a; 


else 
return b; 
1 
Listing 1.134 : MSVC 2013 sans optimisation 
_a$ = 8 
b$ = 12 
my min PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR a$[ebp] 
; comparer A et B: 
cmp eax, DWORD PTR b$[ebp] 
; Sauter si A est supérieur ou égal à B: 
jge SHORT $LN2@my min 
; recharger A dans EAX si autrement et sauter à la sortie 
mov eax, DWORD PTR a$[ebp] 
jmp SHORT $LN3Gmy min 
jmp SHORT $LN3Gmy min ; ce JMP est redondant 
$LN2QGmy min: 
; renvoyer B 
mov eax, DWORD PTR b$[ebp] 
$LN3QGmy min: 
pop ebp 
ret 0 
my min ENDP 
_a$ = 8 
_b$ = 12 
_my max PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR  a$[ebp] 
; comparer A et B: 
cmp eax, DWORD PTR _b$[ebp] 
; sauter si A est inférieur ou égal à B: 
jte SHORT $LN2@my_max 
; recharger A dans EAX si autrement et sauter à la sortie 
mov eax, DWORD PTR  a$[ebp] 
jmp SHORT $LN3Gmy max 
jmp SHORT $LN3Gmy max ; ce JMP est redondant 
$SLN2@my_ max: 
; renvoyer B 
mov eax, DWORD PTR _b$[ebp] 
$LN3@my_max: 
pop ebp 
ret 0 
my max ENDP 


Ces deux fonctions ne différent que de l'instruction de saut conditionnel: JGE («Jump 
if Greater or Equal» saut si supérieur ou égal) est utilisée dans la premiére et JLE 
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(«Jump if Less or Equal » saut si inférieur ou égal) dans la seconde. 


Il y a une instruction JMP en trop dans chaque fonction, que MSVC a probablement 
mise par erreur. 


Sans branchement 


Le mode Thumb d'ARM nous rappelle le code x86: 
Listing 1.135 : avec optimisation Keil 6/2013 (Mode Thumb) 


my_max PROC 

; RO=A 

; R1=B 

; comparer A et B: 
CMP ro ,r1 

; branchement si A est supérieur à B: 
BGT [L0.6| 

; autrement (A«-B) renvoyer R1 (B): 
MOVS ro ,r1 

[L0.6| 

; retourner 
BX lr 
ENDP 

my min PROC 

; RO=A 

; R1=B 

; comparer A et B: 
CMP ro ,r1 

; branchement si A est inférieur à B: 
BLT [L0.14| 

; autrement (A>=B) renvoyer R1 (B): 
MOVS ro, rl 

[L0.14| 

; retourner 
BX lr 
ENDP 


Les fonctions différent au niveau de l'instruction de branchement: BGT et BLT. Il est 
possible d'utiliser le suffixe conditionnel en mode ARM, donc le code est plus court. 


MOVcc n'est exécutée que si la condition est remplie: 


Listing 1.136 : avec optimisation Keil 6/2013 (Mode ARM) 


my max PROC 
; RO=A 
; R1=B 
; comparer A et B: 
CMP ro ,r1 
; renvoyer B au lieu de A en copiant B dans RO 
; cette instruction ne s'exécutera que si A<=B (en effet, LE Less or Equal, 
inférieur ou égal) 
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; si l'instruction n'est pas exécutée (dans le cas ou A>B), 
; A est toujours dans le registre RO 
MOVLE ro, rl 


BX lr 
ENDP 

my min PROC 

; RO=A 

; R1-B 

; comparer A et B: 
CMP ro ,r1 


; renvoyer B au lieu de A en copiant B dans RO 
; cette instruction ne s'exécutera que si A>=B (GE Greater or Equal, 
supérieur ou égal) 
; si l'instruction n'est pas exécutée (dans le cas où A<B), 
; A est toujours dans le registre RO 
MOVGE ro, rl 
BX lr 
ENDP 


GCC 4.8.1 avec optimisation et MSVC 2013 avec optimisation peuvent utiliser l'ins- 
truction CMOVcc, qui est analogue à MOVcc en ARM: 


Listing 1.137 : MSVC 2013 avec optimisation 


my max: 
mov edx, DWORD PTR [esp+4] 
mov eax, DWORD PTR [esp+8] 

; EDX=A 

; EAX-B 

; comparer A et B: 
cmp edx, eax 


; Si A>=B, charger la valeur A dans EAX 
; l'instruction ne fait rien autrement (si A«B) 
cmovge eax, edx 


ret 
my_min: 
mov edx, DWORD PTR [esp+4] 
mov eax, DWORD PTR [esp+8] 
; EDX=A 
; EAX=B 
; comparer A et B: 
cmp edx, eax 


; Si A<=B, charger la valeur A dans EAX 

; l'instruction ne fait rien autrement (si A>B) 
cmovle eax, edx 
ret 


64-bit 


#include <stdint.h> 
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int64 t my max(int64 t a, int64 t b) 
1 
if (a»b) 

return a; 
else 
return b; 


int64 t my min(int64 t a, int64 t b) 


if (a«b) 

return a; 
else 

return b; 


Il y a beaucoup de code inutile qui embrouille, mais il est compréhensible: 


Listing 1.138 : GCC 4.9.1 ARM64 sans optimisation 


my max: 
sub sp, sp, £16 
str x0, [sp,8] 
str X1, [sp] 
ldr X1, [sp,8] 
ldr x0, [sp] 
cmp x1, x0 
ble .L2 
ldr x0, [sp,8] 
b .L3 
.L2: 
ldr x0, [sp] 
L3 
add sp, sp, 16 
ret 
my min: 
sub sp, sp, £16 
str x0, [sp,8] 
str X1, [sp] 
ldr X1, [sp,8] 
ldr x0, [sp] 
cmp x1, x0 
bge .L5 
ldr x0, [sp,8] 
b .L6 
.L5: 
ldr x0, [sp] 
.L6: 


add sp, sp, 16 
ret 
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Sans branchement 


Il n'y a pas besoin de lire les arguments dans la pile, puisqu'ils sont déjà dans les 
registres: 


Listing 1.139 : GCC 4.9.1 x64 avec optimisation 


my max: 
; RDI-A 
; RSI-B 
; comparer A et B: 
cmp rdi, rsi 
; préparer B pour le renvoyer dans RAX: 
mov rax, rsi 
; Si A>=B, mettre A (RDI) dans RAX pour le renvoyer. 
; cette instruction ne fait rien autrement (si A«B) 
cmovge rax, rdi 
ret 


my min: 
; RDI=A 
; RSI-B 
; comparer A et B: 
cmp rdi, rsi 
; préparer B pour le renvoyer dans RAX: 
mov rax, rsi 
; Si A<=B, mettre A (RDI) dans RAX pour le renvoyer. 
; cette instruction ne fait rien autrement (si A>B) 
cmovle rax, rdi 
ret 


MSVC 2013 fait presque la méme chose. 


ARM64 possède l'instruction CSEL, qui fonctionne comme MOVcc en ARM ou CMOVcc 
en x86, seul le nom différe: «Conditional SELect ». 


Listing 1.140 : GCC 4.9.1 ARM64 avec optimisation 


my max: 

; X0-A 

; X1-B 

; comparer A et B: 
cmp x0, x1 

; copier X0 (A) dans X0 si X0>=X1 ou A>=B (Greater or Equal, supérieur ou 

égal) 

H Rapier X1 (B) dans X0 si A<B 
csel x0, x0, x1, ge 
ret 

my min: 

; X0-A 

; X1-B 


; comparer A et B: 
cmp x0, x1 
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; copier X0 (A) dans X0 si X0«-X1 ou A<=B (Less or Equal, inférieur ou égal) 
; copier X1 (B) dans X0 si A>B 
csel x0, x0, x1, le 
ret 


MIPS 
Malheureusement, GCC 4.4.5 pour MIPS n'est pas si performant: 


Listing 1.141 : GCC 4.4.5 avec optimisation (IDA) 


my max: 
; mettre $v1 à 1 si $al<$a0, ou l'effacer autrement (si $al>$a0): 
slt $v1, $al, $a 
; sauter, si $vl est 0 (ou $al>$a0): 
beqz $v1, locret 10 
ceci est le slot de délai de branchement 
; préparer $al dans $vO si le branchement est pris: 
move $v0, $al 
le branchment n'est pas pris, préparer $a0 dans $v0: 
move $v0, $a0 


locret_10: 
jr $ra 
or $at, $zero ; slot de délai de branchement, NOP 


; la fonction min() est la méme, mais les opérandes 
; dans l'instruction SLT sont échangés: 


my min: 
slt $v1, $a0, $al 
beqz $v1, locret 28 
move $v0, $al 
move $v0, $a0 
locret_28: 
jr $ra 
or $at, $zero ; slot de délai de branchement, NOP 


N'oubliez pas le slot de délai de branchement (branch delay slots) : le premier MOVE 
est exécuté avant BEQZ, le second MOVE n'est exécuté que si la branche n'a pas été 
prise. 


1.18.5 Conclusion 
x86 


Voici le squelette générique d'un saut conditionnel: 


Listing 1.142 : x86 


CMP registre, registre/valeur 
Jcc true ; cc=condition code, code de condition 
false: 
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+... le code qui sera exécuté si le résultat de la comparaison est faux 
(false) 

JMP exit 

true: 

+... le code qui sera exécuté si le résultat de la comparaison est vrai 
(true) 

exit: 


ARM 


Listing 1.143 : ARM 


CMP registre, registre/valeur 

Bcc true ; cc=condition code 

false: 

+... le code qui sera exécuté si le résultat de la comparaison est faux 


(false) 
JMP exit 
true: 
+... le code qui sera exécuté si le résultat de la comparaison est vrai 


(true) 
exit: 


MIPS 


Listing 1.144 : Teste si égal à zéro (Branch if EQual Zero) 


BEQZ REG, label 


Listing 1.145 : Teste si plus petit que zéro (Branch if Less Than Zero) en utilisant une 
pseudo instruction 


BLTZ REG, label 


Listing 1.146 : Teste si les valeurs sont égales (Branch if EQual) 


BEQ REG1, REG2, label 


Listing 1.147 : Teste si les valeurs ne sont pas égales (Branch if Not Equal) 


BNE REG1, REG2, label 


Listing 1.148 : Teste si REG2 est plus petit que REG3 (signé) 


SLT REG1, REG2, REG3 
BEQ REG1, label 
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Listing 1.149 : Teste si REG2 est plus petit que REG3 (non signé) 


SLTU REG1, REG2, REG3 
BEQ REG1, label 


Sans branchement 


Si le corps d'instruction conditionnelle est trés petit, l'instruction de déplacement 
conditionnel peut étre utilisée: MOVcc en ARM (en mode ARM), CSEL en ARM64, 
CMOVcc en x86. 


ARM 


Il est possible d'utiliser les suffixes conditionnels pour certaines instructions ARM: 


Listing 1.150 : ARM (Mode ARM) 


CMP registre, registre/valeur 

instrl cc ; cette instruction sera exécutée si le code conditionnel est vrai 
(true) 

instr2 cc ; cette autre instruction sera exécutée si cet autre code 
conditionnel est vrai (true) 

faac CC 


Bien sür, il n'y a pas de limite au nombre d'instructions avec un suffixe de code 
conditionnel, tant que les flags du CPU ne sont pas modifiés par l'une d'entre elles. 


Le mode Thumb possède l'instruction IT, permettant d'ajouter le suffixe conditionnel 
pour les quatre instructions suivantes. Lire à ce propos: 1.25.7 on page 334. 


Listing 1.151 : ARM (Mode Thumb) 


CMP registre, registre/valeur 

ITEEE EQ ; met ces suffixes: if-then-else-else-else 

instrl ; instruction exécutée si la condition est vraie 
instr2 ; instruction exécutée si la condition est fausse 
instr3 ; instruction exécutée si la condition est fausse 
instr4 ; instruction exécutée si la condition est fausse 


1.18.6 Exercice 


(ARM64) Essayez de récrire le code pour listado.1.131 en supprimant toutes les ins- 
tructions de saut conditionnel et en utilisant l'instruction CSEL. 


1.19 Déplombage de logiciel 


La grande majorité des logiciels peuvent étre déplombés comme ca — en cherchant 
l'endroit oü la protection est vérifiée, un dongle (8.8 on page 1081), une clef de 
licence, un numéro de série, etc. 
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Souvent, ca ressemble à ca: 


call check protection 

jz all 0K 

call message box protection missing 
call exit 

all OK: 

; proceed 


Donc, si vous voyez un patch (ou "crack"), qui déplombe un logiciel, et que ce patch 
remplace un ou des octets 0x74/0x75 (JZ/JNZ) par OxEB (JMP), c'est ca. 


Le processus de déplombage de logiciel revient à une recherche de ce JMP. 


Il y a aussi les cas oü le logiciel vérifie la protection de temps à autre, ceci peut étre 
un dongle, ou un serveur de licence qui peut étre interrogé depuis Internet. Dans 
ce cas, vous devez chercher une fonction qui vérifie la protection. Puis, la modifier, 
pour y mettre xor eax, eax / retn,oumov eax, 1 / retn. 


Il est important de comprendre qu'aprés avoir patché le début d'une fonction, sou- 
vent, il y a des octets résiduels qui suivent ces deux instructions. Ces restes consistent 
en une partie d'une instruction et les instructions suivantes. 


Ceci est un cas réel. Le début de la fonction que nous voulons remplacer par return 
1; 


Listing 1.152 : Before 


8BFF mov edi,edi 

55 push ebp 

8BEC mov ebp,esp 
81EC68080000 sub esp,000000868 
A110C00001 mov eax, [00100C010] 
33C5 xor eax,ebp 

8945FC mov [ebp][-4],eax 
53 push ebx 


8B5D08 mov ebx, [ebp][8] 


Listing 1.153 : After 


B801000000 mov eax,1 

C3 retn 

EC in al,dx 
68080000A1 push 0A1000008 
10C0 adc al,al 

0001 add [ecx],al 

3305 xor eax,ebp 
8945FC mov [ebp][-4],eax 
53 push ebx 


8B5D08 mov ebx, [ebp] [8] 
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Quelques instructions incorrectes apparaissent — IN, PUSH, ADC, ADD, aprés lesquelles, 
le désassembleur Hiew (que j'ai utilisé) s'est synchronisé et a continué de désassem- 
bler le reste. 


Ceci n'est pas important — toutes ces instructions qui suivent RETN ne seront jamais 
exécutées, à moins qu'un saut direct se produise quelque part, et ca ne sera pas 
possible en général. 


Il peut aussi y avoir une variable globale booléenne, un flag indiquant si le logiciel 
est enregistré ou non. 


init etc proc 


call check protection or license file 
mov is demo, eax 

retn 

init_etc endp 

save file proc 

mov eax, is demo 

cmp eax, 1 

jz all OK1 


call message box it is a demo no saving allowed 
retn 


:all OK1 
; continuer en sauvant le fichier 


save proc endp 

somewhere else proc 

mov eax, is demo 

cmp eax, 1 

jz all OK 

; contróler si le programme fonctionne depuis 15 minutes 
; sortir si c'est le cas 


; ou montrer un écran fixe 


:all OK2 
; continuer 


somewhere else endp 
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Le début de la fonction check protection or license file() peut étre patché, 
afin qu'elle renvoie toujours 1, ou, si c'est mieux pour une raison quelconques, toutes 
les instructions JZ/JNZ peuvent étre patchées de méme 


Plus sur le patching: 11.2. 


1.20 Blague de l'arrét impossible (Windows 7) 


Je ne me rappelle pas vraiment comment j'ai découvert la fonction ExitWindowsEx() 
dans le fichier user32.dll de Windows 98 (c'était à la fin des années 1990) J'ai pro- 
bablement juste remarqué le nom évocateur. Et j'ai ensuite essayé de la bloquer en 
modifiant son début par l'octet OxC3 byte (RETN). 


Le résultat était rigolo: Windows 98 ne pouvait plus être arrêté. Il fallait appuyer sur 
le bouton reset. 


Ces jours, j'ai essayé de faire de méme dans Windows 7, qui a été créé presque 10 
ans aprés et qui est basé sur une base Windows NT complétement différente. Quand 
méme, la fonction ExitWindowsEx() est présente dans le fichier user32.dll et sert à 
la méme chose. 


Premiérement, j'ai arrété Windows File Protection en ajoutant ceci dans la base de 
registres (sinon Windows restaurerai silencieusement les fichiers systéme modifiés) : 


Windows Registry Editor Version 5.00 


[HKEY LOCAL MACHINENSOFTWAREMMicrosoftNWindows NT\CurrentVersion\Winlogon] 
"SFCDisable"-dword:ffffff9d 


Puis, j'ai renommé c: \windows\system32\user32.dll en user32.dll.bak. J'ai trou- 
vé l’ entrée de l'export ExitWindowsEx() en utilisant Hiew (IDA peut aider de méme) 
et y ai mis l'octet 0xC3. J'ai redémarré Windows 7 et maintenant on ne peut plus l'ar- 
réter. Les boutons "Restart" et "Logoff" ne fonctionnent plus. 


Je ne sais pas si c'est rigolo aujourd'hui ou pas, mais dans le passé, à la fin des 
années 1990, mon ami a pris le fichier user32.dll patché sur une disquette et l'a 
copié sur tous les ordinateurs (à portée de main, qui fonctionnaient sous Windows 
98 (presque tous)) de son université. Plus aucun ordinateur sous Windows ne pouvait 
étre arrété aprés et son professeur d'informatique était rouge. (Espérons qu'il puisse 
nous pardonner aujourd'hui s'il lit ceci maintenant.) 


Si vous faltes ca, sauvegardez tout. La meilleure idée est de lancer Windows dans 
une machine virtuelle. 


1.21 switch()/case/default 


1.21.1 Petit nombre de cas 


#include <stdio.h> 


void f (int a) 
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1 
switch (a) 
1 
case 0: printf ("zero\n"); break; 
case 1: printf ("one\n"); break; 
case 2: printf ("two\n"); break; 
default: printf ("Something unknown\n"); break; 
5s 

}; 

int main() 

1 
f (2); // test 

}; 

x86 


MSVC sans optimisation 


Résultat (MSVC 2010) : 
Listing 1.154 : MSVC 2010 


tv64 = -4 ; size = 4 
_a$ = 8 ; size = 4 
f PROC 
push ebp 
mov ebp, esp 
push ecx 


mov eax, DWORD PTR a$[ebp] 
mov DWORD PTR tv64[ebp], eax 
cmp DWORD PTR tv64[ebp], 0 


je SHORT $LN4@f 
cmp DWORD PTR tv64[ebp], 1 
je SHORT $LN3@f 
cmp DWORD PTR tv64[ebp], 2 
je SHORT $LN2@f 
jmp SHORT $LN1@f 

$LN4@f 


push OFFSET $5G739 ; 'zero', 0aH, 00H 
call printf 

add esp, 4 

jmp SHORT $LN7Gf 


push OFFSET $SG741 ; 'one', 0aH, OOH 
call printf 

add esp, 4 

jmp SHORT $LN7Gf 


push OFFSET $SG743 ; 'two', 0aH, 00H 
call printf 
add esp, 4 
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jmp SHORT $LN7@f 
$LN1@f : 
push OFFSET $SG745 ; ‘something unknown', OaH, 00H 
call printf 
add esp, 4 


$LN7Gf : 
mov esp, ebp 
pop ebp 
ret 0 

_f ENDP 


Notre fonction avec quelques cas dans switch() est en fait analogue a cette construc- 
tion: 


void f (int a) 
{ 
if (a==0) 
printf ("zero\n"); 
else if (a==1) 
printf ("one\n"); 
else if (a==2) 
printf ("two\n"); 
else 
printf ("something unknown\n"); 
}; 


Si nous utilisons switch() avec quelques cas, il est impossible de savoir si il y avait 
un vrai switch() dans le code source, ou un ensemble de directives if(). 


Ceci indique que switch() est comme un sucre syntaxique pour un grand nombre de 
if() imbriqués. 


Il n'y a rien de particuliérement nouveau pour nous dans le code généré, à l'ex- 
ception que le compilateur déplace la variable d'entrée a dans une variable locale 
temporaire tv64 °°. 


Si nous compilons ceci avec GCC 4.4.1, nous obtenons presque le méme résultat, 
méme avec le niveau d'optimisation le plus élevé (-03 option). 


MSVC avec optimisation 


Maintenant compilons dans MSVC avec l'optimisation (/0x) : cl 1.c /Fal.asm /0x 


Listing 1.155 : MSVC 


a$ = 8 ; size = 4 


_f PROC 
mov eax, DWORD PTR _a$[esp-4] 
sub eax, 0 
je SHORT $LN4@f 


93Les variables locales sur la pile sont préfixées avec tv—c’est ainsi que MSVC appelle les variables 
internes dont il a besoin. 
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sub eax, 1 
je SHORT $LN3@f 
sub eax, 1 
je SHORT $LN2@f 
mov DWORD PTR _a$[esp-4], OFFSET $SG791 ; ‘something unknown', 0aH, 
mp | printf 

$LN2@f : 
mov DWORD PTR a$[esp-4], OFFSET $5G789 ; 'two', OaH, OOH 
jmp | printf 

$LN3@f : 
mov DWORD PTR _a$[esp-4], OFFSET $SG787 ; 'one', OaH, 00H 
jmp | printf 

$LN4@f : 
mov DWORD PTR _a$[esp-4], OFFSET $SG785 ; 'zero', 0aH, OOH 
jmp | printf 

f ENDP 


Ici, nous voyons quelques hacks moches. 


Premiérement: la valeurs de a est mise dans EAX et O en est soustrait. Ca semble 
absurde, mais cela est fait pour vérifier si la valeur dans EAX est O. Si oui, le flag 
ZF est mis (e.g. soustraire de O est 0) et le premier saut conditionnel JE (Jump if 
Equal saut si égal ou synonyme JZ —Jump if Zero saut si zéro) va étre effectué et 
le déroulement du programme passera au label $LN4@f, ou le message 'zero' est 
affiché. Si le premier saut n'est pas effectué, 1 est soustrait de la valeur d'entrée et 
si à une étape le résultat est 0, le saut correspondant sera effectué. 


Et si aucun saut n'est exécuté, l'exécution passera au printf() avec comme argu- 
ment la chaine 
'something unknown'. 


Deuxiémement: nous voyons quelque chose d'inhabituel pour nous: un pointeur sur 
une chaíne est mis dans la variable a et ensuite printf() est appelé non pas par 
CALL, mais par JMP. Il y a une explication simple à cela: l'appelant pousse une valeur 
sur la pile et appelle notre fonction via CALL. CALL lui méme pousse l'adresse de 
retour (RA) sur la pile et fait un saut inconditionnel à l'adresse de notre fonction. 
Notre fonction, à tout moment de son exécution (car elle ne contient pas d'instruction 
qui modifie le pointeur de pile) à le schéma suivant pour sa pile: 


* ESP— pointe sur RA 
* ESP*-4— pointe sur la variable a 


D'un autre cóté, lorsque nous appelons printf() ici nous avons exactement la 
méme disposition de pile, excepté pour le premier argument de printf(), qui doit 
pointer sur la chaîne. Et c'est ce que fait notre code. 


Il remplace le premier argument de la fonction par l'adresse de la chaîne et saute à 
printf(), comme si nous n'avions pas appelé notre fonction f (), mais directement 
printf(). printf() affiche la chaîne sur la sortie standard et ensuite exécute l'ins- 
truction RET qui POPs RA de la pile et l'exécution est renvoyée non pas à f() mais 
plutôt à l'appelant de f(), ignorant la fin de la fonction f(). 
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Tout ceci est possible car printf () est appelée, dans tous les cas, tout à la fin de la 
fonction f (). Dans un certain sens, c'est similaire à la fonction Longjmp()?^. Et bien 
sür, c'est fait dans un but de vitesse d'exécution. 


Un cas similaire avec le compilateur ARM est décrit dans la section «printf() avec 
plusieurs arguments », ici (1.11.2 on page 75). 


?4Wikipédia 
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OllyDbg 


Comme cet exemple est compliqué, tracons-le dans OllyDbg. 


OllyDbg peut détecter des constructions avec switch(), et ajoute des commentaires 
utiles. EAX contient 2 au début, c'est la valeur du paramétre de la fonction: 


CPU - main thread, module few 
5 8B4424 04 MOY EAX, DWORD PTR SS: [ARG. 1] 
* 83E8 00 sul A 

74 30 Je SHORT GBFF1039 
48 C EA; 

74 1F Je SHORT S@FF102B 
48 DEC ERX 


74 DE Je SHORT GGFF1910 
Cr4424 04 MOU DWORD PTR SS "something unknowi 


"two", case 2 of 


I "Hi" 


BFF. 
OFF 1684 


We 
EIP BOFF1004 few. 
a E 


“one”, case 1 of 


ca 

SS: CARG. 11, OFFSET Garrsaa zero”, case 8 of & " 

DS: [C&HSUCR188. printf?1 21 GCFFFFFFFF) 
sau YEFDDOBO(FFF) 
TO @(FFFFFFFF) 
Da 
0 8 


RETURN from f 
FF FF FF EE a Ü ASCII "phe'* 
FE 8  4TuFiraKil 
a H(* hN# 


Fig. 1.42: OllyDbg : EAX contient maintenant le premier (et unique) argument de la 
fonction 
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0 est soustrait de 2 dans EAX. Bien sûr, EAX contient toujours 2. Mais le flag ZF est 
maintenant à O, indiquant que le résultat est différent de zéro: 


CPU - main thread, module few 


84424 M4 MOV EAX, DWORD PTR SS:tRRG.11 


Switch (cases 8..2, 4 e 
EC ERS E ASCII "H(w" 
Je SHORT 6@FF192B w 8 

DEC ERX 


Qe ROOOA 


JZ SHORT BOFFiBD de 
MOY DWORD PTR SS:CARG.11,0FFSET BOFF3O1i ASCII "something unknown [EST 5 
å PTR DS: LCEMSUCR109, printf >] pere 


few.aaFFS 


84 


PTR SS: [ARG.11,OFFSET OOFF3B11 ASCII "two", case 2 of 


à PTR DS: L<&MSUCR188. printf >] > BOFF1007 few. OOFF1O 

GOFF 192 64 PTR $3:CARG.1],0FFSET GGFF300! ASCII "oneB", case 1 of 0028 32bit OLFFFFFFFF) 
GOFF 1933 F; E PTR DS: L<&MSUCR188. printf >] DE OLEFEEEFEE) 
QGFF 1939 64 PTR SS: LARG. 11,0FFSÈT BOFF300l ASCII "zercB", case © of IE yaad, 
QGFF 1941 a PTR DS: [<eMSUCRIBO. pr int£ >] 3 ) 


j 32bit BLFFFFFFFF) 
jit PEFDDBBBLFFF) 
2bit B(FFFFFFFF) 
000 ERROR 
NB, NE, A, NS, PO, GE, G) 


LastErr 
26809262 


SUCCESS 


from 
RETURN from 


unknown ASCII "phw'" 


a B 4TuFiraKil 
H(* hN# 


Fig. 1.43: OllyDbg : SUB exécuté 
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DEC est exécuté et EAX contient maintenant 1. Mais 1 est différent de zéro, donc le 
flag ZF est toujours à 0: 


CPU - main thread, module few 


MOV EAX, DWORD PTR SS:LRRG.11 
SUB EAX, Ø 
Je SHORT 00FF1039 
DEC EAX 

DOFF102B 
DEC ERX 
Je SHORT GaGFFi181D 
MOV DWORD PTR SS: [ARG.11,OFFSET 60FF361; ASCII "something unknown 61 
PTR DS: L£&HSUCRIBB.printf?1 GGFF33A8 few. DOFF33A8 
PTR SS: [ARG.11,OFFSET BOFF3011 ASCII "tug", case 2 of eee, en pes 
PTR DS: [<2MSUCR10B. printf >] 
PTR SS: [ARG.1],OFFSET GGFF308 ASCII "one", case 1 of 
PTR DS: [<2MSUCR10B. printf >] 


PTR SS: [ARG.11,0FFSET GOFF3001 ASCII "zero", case 8 of 
DS: C<&MSUCR198. printf >] 


8B4424 84 
S3ES 66 Switch (cases 8..2, 4 e 
74 38 


ASCII "H(«" 


48 
74 1F 
8 


BLFFFFFFFF) 
BLFFFFFFFF) 
BLFFFFFFFF) 
BLFFFFFFFF) 
7EFDDOBO(FFF) 
t BLFFFFFFFF) 


moo 


rom 
RETURN from 


unknown - ASCII "pue 


8 4TuFiraKil 
H(* hN* 


Fig. 1.44: OllyDbg : premier DEC exécuté 
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Le DEC suivant est exécuté. EAX contient maintenant O et le flag ZF est mis, car le 
résultat devient zéro: 


CPU - main thread, module few 


$ 8B4424 04 MOU EAX, DWORD PTR SS: LARG. 1] 
SUB _EAX, Ø Switch (cases 8..2, 
Je SHORT BarFi1839 


Rd mE BOFF102B 


de SHORT. — = 
R SS:CARG.1],OFFSET BOFF361; ASCII "something unknown 
D PTR DS: [<2MSUCRIBB. printf >I 

SS: CARG. 1], OFFSET OOFF301 “tu”, case 2 of 


UC 21 
PTR SS:CARG.1],OFFSET GOFF290; ASCII "oneE", case 1 of 
PTR DS: [<2MSUCR100. printf>] 


4e 


OFF190D 
Q(FFFFFFFF) 


PTR SS:CARG.1],0FFSET GGFF300l ASCII "zercE", case 0 of dde 
PTR DS: L<&MSUCR1908. printf >] MEM 
7TEFDDaaatFFF) 


BLFFFFFFFF) 


rom 
RETURN from f: 


CII "phe" 


he 
HC# 
amkF 


Og 


4TuFirAKil 
(e hN# 


IO He 
re 


Fig. 1.45: OllyDbg : second DEC exécuté 


OllyDbg montre que le saut va étre effectué (Jump is taken). 
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Un pointeur sur la chaine «two » est maintenant écrit sur la pile: 


$ SB4424 84 MOU EAX, DWORD PTR SS: [ARG. 1] 


- 83E8 00 SUB _EAX,@ Switch (cases 8..2, 4 e 
tv p sa JZ SHORT G@FF1939 
I p iF Je SHORT BOFF102B 


a 
) UU ceu 


vrr4 GE Je SHORT G@FF1810 . 

C74424 84 MOV DWORD PTR SS: CARG.11,OFFSET GBFFS81: ASCII "something unknown 
FF2S Aged DWORD PTR DS: EEES] 

€ a DWORD PTR SS: [ARG.11, G6FF3911 ASCII "tucE", case 2 of 
a DWORD PTR DS:L4&HMSUCR188.printf»1 

a4 DWORD PTR SS: CARG.11,OFFSET BOFF300: ASCII "oneg", case 1 of 
a DWORD PTR DS:L4&HMSUCR188.printf»1 

a4 DWORD PTR SS: CARG.11,OFFSET BOFF3001 ASCII "zero", case 8 of 
a DWORD PTR DS:E4&MSUCR188.printf»1 


H 


few. BOFF161D 


jit BLFFFFFFFF) 
jit GLFFFFFFFF) 
jit BLFFFFFFFF) 
jit GCFFFFFFFF]) 
jit 7EFODGGG(FFF) 
GUFFFFFFFF) 


= 
ù 

A 
m 


mm=few. DBFF3616, ASCII 
Stack [Ø001EF850]=2 
Jump from BFF100D 


AA 
ethin y : yb CHJ + RETURN from 


ct 
unknownBl 4 ASCII "pnw" 


8 4TuFipakil 
H(* hN# 


Fig. 1.46: OllyDbg : pointeur sur la chaíne qui va étre écrite à la place du premier 
argument 


Veuillez noter: l'argument de la fonction courante est 2, et 2 est maintenant sur la 
pile, à l'adresse 0x001EF850. 
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MOV écrit le pointeur sur la chaine à l'adresse 0x001EF850 (voir la fenétre de la pile). 
Puis, le saut est effectué. Ceci est la première instruction de la fonction printf () 


dans MSVCR100.DLL (Cet exemple a été compilé avec le switch /MD) : 


7S 15 

ES 72B2FAFF 
C700 1600000 
ES 09599268 


PUSH BC 

PUSH 65445630 
CALL 6E3F0950 
XOR EAX, EAX 
XOR ESI, ESI 
CMP DWORD PTR SS: [EBP+8],ESI 
SETNE AL 

CMP ERX,ESI 

JNE SHORT 6E4455B3 
CALL _errno 


MOV DWORD PTR DS: [EAXJ1,16 
CALL _invalid_parameter_noinfo 


ADD EAX, EBX 
PUSH EAX 


W 
unknowng 


8  4TuFTaKil 
H(* hN# 


CHSUCR188. errno 
CONST 16 => EXDEU 
CHSUCR188. invalid parar 


E i1=1 
MSUCR100. 6E3FA9B9 


ethin 


INT MSUCR188.printf(forr a 


EDI 6 33 fe 
EIP 6E445584 M 


printf 


E Gt FFFFFFFF) 

83C8 FF OR ERR, FFFFFFFF i 

EB SF JMP SHORT 6E445612 Oc EEEEEFEE) 

ES 7SE4FAFF |CALL . iob func O FFFFFFFF} 

6A 20 PUSH 28 7EFDDGGO( FFF) 
POP EBX GCFFFFFFFF) 


E 


Fig. 1.47: OllyDbg : première instruction de printf() dans MSVCR100.DLL 


Maintenant printf () traite la chaîne à l'adresse 0x00FF3010 comme c'est son seul 
argument et l'affiche. 
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Ceci est la dernière instruction de printf() : 


E PUSH ERX 
56 PUSH ESI 
FF7S 88 PUSH DWORD PTR SS: LEBP+81 
ES 49E4FAFF |CALL . iob func 
A s 
ES 2E710100 |CALL 6E45C710 ESAE rnm 
8945 Ed opp [MOV DWORD PIR SS: CEBP-1C1, EAX A HE 
mM Æ © 
E ADD ERR EBR O GOFFS3AB few. OFF f 
50 PUSH EAX [ EIP 6E445617 MSUCR100. 6E445617 


57 PUSH EDI bit 6 
EB ACBØFEFF | CALL éE4oocnc ng age pial dal 


HDD ESP, 18 E 

C745 FC FEFFIMOU DWORD PTR SS: CEBP-41, -2 PICO dala 
5B4 E4 |HOU-ERK, DUORD PTR SS: LEBP-10] a lin 
EB 7EBSFAFF |CALL 6E3FB995 i bit BIFEFEFFFES 


C3 RETN 
6445618 ES 13E4FAFF | CALL . iob func 
6E44561D 8308 29 ADD EAX, 20 


[ 4 

6l 7 MSUCR100.6E445617 
86820 

EEE) 


o 
e 


Argi 
MSUCR109. 6E4006AC 


OH ND TU 
DOSOr ar: 


a 06 466 6 
ea aa 6 65/7 E ea 5 thin 
7 unknownEl 


8 4TuFrakil 
H(* hh* 


aa aa 


88 90/09 gg 
a an 
aa ea 


Fig. 1.48: OllyDbg : derniére instruction de printf() dans MSVCR100.DLL 


La chaine «two » vient juste d'étre affichée dans la fenétre console. 
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Maintenant, appuyez sur F7 ou F8 (enjamber) et le retour ne se fait pas sur f (), mais 
sur main() : 


EEE] 


EFS5@) PTR to ASCII "tucg" 
E 


INT3 
6A 02 PUSH | ey ORES 
ES ASFFFFFF |CALL GGFF1900 di doc 
8304 84 » DOFF1057 few. DOFF1057 
En ROR EAR, EAX C E jit BLFFFFFFFF) 
68 2014FFOO | PUSH BØFF142A E HE OLEEEEEEEEN 
Es 6030900 |CALL GOFFISED T dad 
MOU EAX, DWORD PTR DS: COFF30741 A. ie EBD EF) 
MOU DWORD PTR SS: CLOCAL.0], OFFSET BOFF3 few. GFF3064 Mas 
PUSH DWORD PTR DS: COFF30781 8 e 
ORD PTR DS: LOFF3064], EAX : 
PUSH OFFSET @FF3054 Aira = ASCII "H(w" 
PUSH OFFSET G0FF2058 Hrs? = ASCII "hM" 


ASCII "twcg" 
RETURN from fe 


RSCII 


"phe" 


8 4TuFiraKil 
H(* hN# 


Fig. 1.49: OllyDbg : retourne à main() 


Oui, le saut a été direct, depuis les entrailles de printf() vers main(). Car RA 
dans la pile pointe non pas quelque part dans f (), mais en fait sur main(). Et CALL 
Ox00FF1000 a été l'instruction qui a appelé f(). 


ARM: avec optimisation Keil 6/2013 (Mode ARM) 


.text:0000014C f1: 

.text:0000014C 00 00 50 E3 CMP RO, +0 

.text:00000150 13 OE 8F 02 ADREQ RO, aZero ; "zeroXn" 
.text:00000154 05 00 00 0A BEQ loc 170 

.text:00000158 01 00 50 E3 CMP RO, +1 

.text:0000015C 4B OF 8F 02 ADREQ RO, a0ne ; “one\n" 
.text:00000160 02 00 00 0A BEQ loc 170 

.text:00000164 02 00 50 E3 CMP RO, +2 

.text:00000168 4A OF 8F 12  ADRNE RO, aSomethingUnkno ; "something 


unknown\n" 
.text:0000016C 4E OF 8F 02 ADREQ RO, aTwo ; "twoin" 


. text: 00000170 


. text: 00000170 loc_170: ; CODE XREF: f1+8 
. text: 00000170 ; f1+14 
.text:00000170 78 18 00 EA B _ 2printf 


A nouveau, en investiguant ce code, nous ne pouvons pas dire si il y avait un switch() 
dans le code source d'origine ou juste un ensemble de déclarations if(). 
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En tout cas, nous voyons ici des instructions conditionnelles (comme ADREQ (Equal)) 
qui ne sont exécutées que si RO = 0, et qui chargent ensuite l'adresse de la chaîne 
«zero\n» dans RO. L'instruction suivante BEQ redirige le flux d'exécution en loc 170, 
si RO — 0. 


Le lecteur attentif peut se demander si BEQ s'exécute correctement puisque ADREQ 
a déjà mis une autre valeur dans le registre RO. 


Oui, elle s'exécutera correctement, car BEQ vérifie les flags mis par l'instruction CMP 
et ADREQ ne modifie aucun flag. 


Les instructions restantes nous sont déjà familiéres. Il y a seulement un appel à 
printf(), à la fin, et nous avons déjà examiné cette astuce ici (1.11.2 on page 75). 
A la fin, il y a trois chemins vers printf(). 


La dernière instruction, CMP RO, #2, est nécessaire pour vérifier si a = 2. 


Si ce n'est pas vrai, alors ADRNE charge un pointeur sur la chaine «something unk- 
nown |n» dans RO, puisque a a déjà été comparée pour savoir s'elle est égale à 0 ou 
1, et nous sommes sürs que la variable a n'est pas égale à l'un de ces nombres, à 
ce point. Et si R0 = 2, un pointeur sur la chaîne «two\n» sera chargé par ADREQ dans 
RO. 


ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


. text: 000000D4 fl: 

.text:000000D4 10 B5 PUSH {R4,LR} 

. text: 000000D6 00 28 CMP RO, 40 

.text:000000D8 05 DO BEQ zero case 

.text:000000DA 01 28 CMP RO, £1 

.text:000000DC 05 DO BEQ one case 

.text:000000DE 02 28 CMP RO, #2 

.text:000000E0 05 DO BEQ two case 

.text:000000E2 91 AO ADR RO, aSomethingUnkno ; "something 
unknown\n" 

. text: Q00000E4 04 EO B default_case 

.text:000000E6 zero case: ; CODE XREF: f1+4 

.text:000000E6 95 AO ADR RO, aZero ; "zero^n" 

.text:000000E8 02 EO B default case 

.text:000000EA one case: ; CODE XREF: f1+8 

.text:000000EA 96 AO ADR RO, aOne ; “one\n" 

. text: Q00000EC 00 EO B default_case 

. text :000000EE two_case: ; CODE XREF: f1+C 

.text:000000EE 97 AO ADR RO, aTwo ; “two\n" 

.text:000000F0 default case ; CODE XREF: f1+10 

.text:000000F0 ; f1+14 

.text:000000F0 06 FO 7E F8 BL . 2printf 

.text:000000F4 10 BD POP {R4,PC} 


Comme il y déja été dit, il n'est pas possible d’ajouter un prédicat conditionnel a la 
plupart des instructions en mode Thumb, donc ce dernier est quelque peu similaire 
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au code CISC-style x86, facilement compréhensible. 


ARM64: GCC (Linaro) 4.9 sans optimisation 


.LC12: 


.string "zero" 


.LC13: 


.string "one" 


.LC14: 


.string "two" 


.LC15: 


.string "something unknown" 


f12: 

stp 
add 
str 
ldr 
cmp 
beq 
cmp 
beq 
cmp 
bne 
adrp 
add 
bl 


.L34: 


.L35: 
adrp 
add 
bl 
b 
.L38: 
adrp 
add 
bl 
nop 
.L32: 
ldp 
ret 


x29, x30, [sp, -32]! 
x29, sp, 0 

w0, [x29,28] 

w0, [x29,28] 

w0, 1 


L38 ; sauter au label par défaut 
"zero" 

x0, x0, :lo12:.LC12 

puts 

.L32 


x0, .LC13 ; "one" 
x0, x0, :1012:.LC13 
puts 

.L32 


x0, .LC14 ; "two" 
x0, x0, :lo12:.LC14 
puts 

.L32 


x0, .LC15 ; "something unknown" 


x0, x0, :1012:.LC15 
puts 


x29, x30, [sp], 32 


Le type de la valeur d'entrée est int, par conséquent le registre WO est utilisé pour 
garder la valeur au lieu du registre complet X0. 


Les pointeurs de chaîne sont passés à puts() en utilisant la paire d'instructions 
ADRP/ADD comme expliqué dans l'exemple «Hello, world! » : 1.5.3 on page 33. 


ARM64: GCC (Linaro) 4.9 avec optimisation 


f12: 
cmp w0, 1 
beq .L31 
cmp w0, 2 
beq .L32 
cbz w0, .L35 
; cas par défaut 
adrp x0, .LC15 ; "something unknown" 
add x0, x0, :lo12:.LC15 
b puts 
.L35: 
adrp x0, .LC12 ; "zero" 
add x0, x0, :lo12:.LC12 
b puts 
.L32: 
adrp x0, .LC14 ; "two" 
add x0, x0, :lo12:.LC14 
b puts 
.L31: 
adrp x0, .LC13 ; "one" 
add x0, x0, :lo12:.LC13 
b puts 


Ce morceau de code est mieux optimisé. L'instruction CBZ (Compare and Branch on 
Zero comparer et sauter si zéro) effectue un saut si WO vaut zéro. Il y a alors un saut 
direct à puts() au lieu de l'appeler, comme cela a été expliqué avant: 1.21.1 on 


page 205. 


MIPS 
Listing 1.156 : GCC 4.4.5 avec optimisation (IDA) 
f: 
lui $gp, ( gnu local gp >> 16) 
; est-ce 1? 
li $v0, 1 
beq $a0, $v0, loc 60 
la $gp, ( gnu local gp € OxFFFF) ; slot de délai de 
branchement 
; est-ce 2? 
li $v0, 2 
beq $a0, $v0, loc 4C 
or $at, $zero ; slot de délai de branchement, NOP 
; jump, if not equal to 0: 
bnez $a0, loc 38 
or $at, $zero ; slot de délai de branchement, NOP 
; Cas zéro: 
lui $a0, ($LCO >> 16) # "zero" 
lw $t9, (puts € OxFFFF) ($gp) 
or $at, $zero ; slot de délai de branchement, NOP 
jr $t9 
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la $20, ($LCO € OxFFFF) # "zero" ; slot de délai de 
branchement 
loc 38: # CODE XREF: f+1C 
lui $a0, ($LC3 >> 16) # "something unknown" 
lw $t9, (puts & OxFFFF) ($gp) 
or $at, $zero ; slot de délai de branchement, NOP 
jr $t9 
la $20, ($LC3 € OxFFFF) # "something unknown" ; slot de 
délai de branchement 
loc 4C: # CODE XREF: f+14 
lui $a0, ($LC2 >> 16) # "two" 
lw $t9, (puts & OxFFFF) ($gp) 
or $at, $zero ; slot de délai de branchement, NOP 
jr $t9 
la $20, ($LC2 € OXFFFF) £ "two" ; slot de délai de 
branchement 
loc 60: # CODE XREF: f+8 
lui $a0, ($LC1 >> 16) # "one" 
lw $t9, (puts & OxFFFF) ($gp) 
or $at, $zero ; slot de délai de branchement, NOP 
jr $t9 
la $20, ($LC1 € OXFFFF) # "one" ; slot de délai de 
branchement 


La fonction se termine toujours en appelant puts(), donc nous voyons un saut à 
puts() (JR: «Jump Register ») au lieu de «jump and link ». Nous avons parlé de ceci 
avant: 1.21.1 on page 205. 


Nous voyons aussi souvent l'instruction NOP aprés LW. Ceci est le slot de délai de 
chargement («load delay slot ») : un autre slot de délai (delay slot) en MIPS. 


Une instruction suivant LW peut s'exécuter pendant que LW charge une valeur depuis 
la mémoire. 


Toutefois, l'instruction suivante ne doit pas utiliser le résultat de LW. 


Les CPU MIPS modernes ont la capacité d'attendre si l'instruction suivante utilise le 
résultat de LW, donc ceci est un peu démodé, mais GCC ajoute toujours des NOPs 
pour les anciens CPU MIPS. En général, ca peut étre ignoré. 


Conclusion 


Un switch() avec peu de cas est indistinguable d'une construction avec if/else, par 
exemple: listado.1.21.1. 


1.21.2 De nombreux cas 


Si une déclaration switch() contient beaucoup de cas, il n'est pas trés pratique 
pour le compilateur de générer un trop gros code avec de nombreuses instructions 
JE/JNE. 
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#include <stdio.h> 


void f (int a) 


{ 
switch (a) 
{ 
case 0: printf ("zero\n"); break; 
case 1: printf ("one\n"); break; 
case 2: printf ("two\n"); break; 
case 3: printf ("three\n"); break; 
case 4: printf ("four\n"); break; 
default: printf ("Something unknown\n"); break; 
}; 

}; 

int main() 

1 
f (2); // test 

}; 

x86 


MSVC sans optimisation 


Nous obtenons (MSVC 2010) : 
Listing 1.157 : MSVC 2010 


tv64 = -4 ; size = 4 
_a$ = 8 ; size = 4 
_f PROC 

push ebp 

mov ebp, esp 

push ecx 


mov eax, DWORD PTR a$[ebp] 
mov DWORD PTR tv64[ebp], eax 
cmp DWORD PTR tv64[ebp], 4 
ja SHORT $LN1@f 
mov ecx, DWORD PTR tv64[ebp] 
jmp DWORD PTR $LN11@f [ecx*4] 
$LN6Q@f : 
push OFFSET $5G739 ; 'zero', 0aH, 00H 
call printf 


add esp, 4 
jmp SHORT $LN9QGf 
$LN5Gf : 


push OFFSET $SG741 ; 'one', 08H, OOH 
call printf 


add esp, 4 
jmp SHORT $LN9QGf 
$LN4@f : 


push OFFSET $SG743 ; 'two', 0aH, OOH 
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call printf 
add esp, 4 
jmp SHORT $LN9@f 
$LN30f : 
push OFFSET $SG745 ; 'three', 0aH, OOH 
call printf 
add esp, 4 
jmp SHORT $LN9@f 
$LN2Gf : 
push OFFSET $SG747 ; 'four', 0aH, 00H 
call printf 
add esp, 4 
jmp SHORT $LN9@f 
$LN1@f : 
push OFFSET $SG749 ; ‘something unknown', OaH, 00H 
call printf 
add esp, 4 


$LN9Gf: 
mov esp, ebp 
pop ebp 
ret 0 
npad 2 ; aligner le label suivant 
$LN116f: 
DD $LN6af ; 0 
DD $LN5@f ; 1 
DD $LNAGf ; 2 
DD $LN3Gf ; 3 
DD $LN2Gf ; 4 
_f ENDP 


Ce que nous voyons ici est un ensemble d’appels a printf() avec des arguments 
variés. Ils ont tous, non seulement des adresses dans la mémoire du processus, mais 
aussi des labels symboliques internes assignés par le compilateur. Tous ces labels 
ont aussi mentionnés dans la table interne $LN11@f. 


Au début de la fonctions, si a est supérieur a 4, l'exécution est passée au labal $LN1@f, 
ou printf() est appelé avec l'argument 'something unknown'. 


Mais si la valeur de a est inférieure ou égale a 4, elle est alors multipliée par 4 et 
ajoutée à l'adresse de la table $LN11@f. C'est ainsi qu'une adresse à l'intérieur de 
la table est construite, pointant exactement sur l'élément dont nous avons besoin. 
Par exemple, supposons que a soit égale à 2. 2 + 4 = 8 (tous les éléments de la table 
sont adressés dans un processus 32-bit, c'est pourquoi les éléments ont une taille 
de 4 octets). L'adresse de la table $LN11@f + 8 est celle de l'élément de la table ou 
le label $LN4@f est stocké. JMP prend l'adresse de $LN4@f dans la table et y saute. 


Cette table est quelquefois appelée jumptable (table de saut) ou branch table (table 
de branchement)?*. 


Le printf() correspondant est appelé avec l'argument 'two'. 
Littéralement, l'instruction jmp DWORD PTR $LN11@f [ecx*4] signifie sauter au DWORD 


25L'ensemble de la méthode était appelé computed GOTO (GOTO calculés) dans les premières versions 
de ForTran: Wikipédia. Pas trés pertinent de nos jours, mais quel terme! 
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qui est stocké à l'adresse $LN11@f + ecx * 4. 


npad (.1.7 on page 1347) est une macro du langage d'assemblage qui aligne le 
label suivant de telle sorte qu'il soit stocké à une adresse alignée sur une limite de 
4 octets (ou 16 octets). C'est trés adapté pour le processeur puisqu'il est capable 
d'aller chercher des valeurs 32-bit dans la mémoire à travers le bus mémoire, la 
mémoire cache, etc., de facons beaucoup plus efficace si c'est aligné. 
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OllyDbg 


Essayons cet exemple dans OllyDbg. La valeur d'entrée de la fonction (2) est chargée 
dans EAX : 


PUSH EBP 

MOU EBP,ESP 

51 PUSH ECX 

8845 98 MOU EAX, DWORD PTR SS: [EBP+8] 
8945 FC MOU DWORD PTR SS:LEBP-41,ERX 
837D FC 64 | CMP DWORD PTR SS:LEBP-41,4 

77 SA JA SHORT B10B106A 

8B4D FC MOV ECX, DWORD PTR SS: [EBP-4] 
FF248D 7C100/ JMP DWORD PTR DS: [ECX*4+10B107C] 
68 9039001 | PUSH OFFSET 01083000 format = 
FF1S AB20080!| CALL DWORD PTR DS: C<&MSUCR188.printf>1 [LMSUCRIDO. 
8304 04 ADD ESP, 4 

EB 4E JMP SHORT 01081078 
68 9839091 | PUSH OFFSET 01063008 format = 
FF1S AZAOLA CALL DWORD PTR DS: C<&MSUCR198.printf>1 [LMSUCRIDO. 
83C4 84 ADD ESP, 4 

EB 3E JMP SHORT 01081078 
68 10300801 | PUSH OFFSET 01083010 format = 
FF15 8620666) CALL DWORD PTR DS:L4&MSUCR188.printf?1 |CMSUCR100. 


83C4 04 ADD ESP, 4 
EB_2E JMP SHORT 01081078 


it OLFFFFFFFF) 
t B(FFFFFFFF) 
t B(FFFFFFFF) 
BLFFFFFFFF) 
TEFDDBOBLFFF) 
BLFFFFFFFF) 


0009 ERROR SUCCESS 
(NO, NB, E, BE, HS, PE, GE, LE) 
E 


Kore D AU 


R10 
3| RETURN from lot 
RETURN from Lot 


"PrhsesHT 
(+ hno 


Fig. 1.50: OllyDbg : la valeur d'entrée de la fonction est chargée dans EAX 


224 


La valeur entrée est testée, est-elle plus grande que 4? Si non, le saut par «défaut » 
n'est pas pris: 


CPU - main threa 


PUSH_EBP 

HOU | EBP, ESP 

PUSH_ECX 

MOV EAX, DWORD PTR SS: [EBP+8] 

MOU DWORD PTR SS: CEBP-4],EAX 

837D FC 84 |CMP DWORD PTR SS:LEBP-41,4 
JA SHORT 010B106A 


SA 
8B4D FC MOV ECX, DWORD PTR SS: [EBP-4] 
FF2480 zc1aal JME DWORD PTR DS: LECH#4+108107C1 
8 99399891 | PUSH OFFSET 010B3001 format = 
CALL DUORD PTR DS: Eensucr1on.priner>1 |LiSUcRi08. 
JMP SHORT 91981078 
PUSH OFFSET 01062008 format - 
CALL DWORD PTR DS:LXMSUCRIOB.print£?l |LIISUCR100, 
JMP SHORT 91981078 FS E 
68 10300801 |PUSH OFFSET 01083010 . format = GS @826 Sebit OLFFFFFFFE) 
E Cs CALL DWORD PTR DS: E«&MSUCR188.printf»1 MSUCR100. LastErr 00000000 ERROR_SUCCESS 
EB 2E JMP SHORT 01061078 kas? 00000293 (NO,B,NE,BE,S,PO,L,LE) 


a 0099 0099 09009 AGGA 
gogg 9000 9666 9000 
po 6600 

a gog 


ve 


lot.B10B3: 
lot .010B100E 


bit B(FFFFFFFF) 
it B(FFFFFFFF) 
bit BLFFFFFFFF) 
2bit B(FFFFFFFF) 
2bit 7EFDDOBALFFF) 


< 


< 


NETO 


4| Zero) ü 1 À 4 
two three - 9 ; a8| RETURN from 
four someth in 
a unknown 


3| RETURN from 


2|m B '"rh*esr 
8 He hNe 


290009 
Ooooooo 
2000@ 


66 66 aa 
a Gà 66 Ga 


Fig. 1.51: OllyDbg : 2 n'est pas plus grand que 4: le saut n'est pas pris 
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Ici, nous voyons une table des sauts: 


format = 


MSUCR188, 


format = : o 
MSUCR100.printf>1 MSUCR16B. 1 al FFFFFFFF 

7EFDDaaatFFF) 
Format = BCFFFFFFFF) 
format = 


&HSUCR1868.printf»1 MSUCR100. 


8| RETURN from lot.B10B100t 


98| RETURN from lot.B10B109€ 


85 C8 79 08 6A 88 ES AB a2 

ES 68 05 66 66 

75 BB 53 53 6A 61 53 FF 

FC 64 A1 18 00 G6 GB SB 70 
BF BS 22 68 01 53 56 57 FF 15 30 20 OB 01 3 
74 19 C6 75 08 33 F6 46 89 75 E4 EB 10 6: 
G3 00 00 FF 15.24 20 OB 01 EB DA 33 F6 46 Al 


Fig. 1.52: OllyDbg : calcul de l'adresse de destination en utilisant la table des sauts 


Ici, nous avons cliqué «Follow in Dump» > «Address constant », donc nous voyons 
maintenant la jumptable dans la fenêtre des données. Il y a 5 valeurs 32-bit*. ECX 
contient maintenant 2, donc le troisième élément (peut être indexé par 2°”) de la 
table va étre utilisé. Il est également possible de cliquer sur «Follow in Dump» > 
«Memory address » et OllyDbg va montrer l'élément adressé par l'instruction JMP. Il 
s'agit de 0x010B103A. 


96Elles sont soulignées par OllyDbg car ce sont aussi des FIXUPs: 6.5.2 on page 989, nous y reviendrons 
plus tard 
97À propos des index de tableaux, lire aussi: 3.22.3 on page 770 
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Aprés le saut, nous sommes en 0x010B103A : le code qui affiche «two » va étre exé- 
cuté: 


CPU - main thread, module lot 


$ 55 PUSH EBP 

SBEC MOU EBP,ESP 

51 PUSH ECX 

SB45 88 MOV EAX, DWORD PTR SS: [EBP+8] 
8945 FC MOU DWOR SERBE 21 ERX 
8370 FC 84 | CMP DWORI : [EBP-4], 4 
77 SA Ji a18B186R 


8840 FC MOU ECX, DWORD PTR SS:LEBP-41 
pta c il eme 
format - "aer 
FF1S AB20086| CALL DWORD PTR DS: C<EMsucr100. pr i LusucRiog. prints ^ Ø10B103A lot.G19B193 
2304 04 RDD ESP,4 E bit OCFFFFFFFF) 
~ EB AA ane SHORT g10B1078 Eu |: bit OLFFFFFFFF) 
> H OFFSET 0101 (formar = "on bit GLEFFFEEEFÀ 
: Pris Bacüóbo CALL DUORD PTR Bet EcertsucR100. pri LHSUCRIOG. pr ine? pandas 
. E 04 ADI 5 bit 7EFDDØØLFFF) 
«v EB 3E "He SHORT 01981078 : 3 Dit OCFFFFFFFF) 
> E 10300801 | PUSH OFFSET 01083010 | format = "twog” 
* FFIS CALL DWORD PTR DS: [<2MSUCR100. pr i LMSUCR106. printf 
83C4 04 ADD ESP,4 
ev EB 2E JMP SHORT 91981078 
Stack LOOGCFDH4]- lor. 01063068 
Imm-lot.G18B3818, ASCII "two" 


8| RETURN from Llot.818B188t 


8| RETURN from lot.818B189t 


Fig. 1.53: OllyDbg : maintenant nous sommes au cas: label 


GCC sans optimisation 


Voyons ce que GCC 4.4.1 génére: 
Listing 1.158 : GCC 4.4.1 


public f 
f proc near ; CODE XREF: main+10 


var 18 - dword ptr -18h 
arg 0 - dword ptr 8 


push ebp 

mov ebp, esp 

sub esp, 18h 

cmp [ebp+arg 0], 

ja short loc 8048444 

mov eax, [ebp+arg 0] 

shl eax, 2 

mov eax, ds:off 804855C[eax] 
jmp eax 


loc 80483FE: ; DATA XREF: .rodata:off 804855C 
mov [esp+18h+var_18], offset aZero ; "zero" 
call | puts 
jmp short locret 8048450 
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loc_804840C: DATA XREF: .rodata:08048560 


mov [esp+18h+var_18], offset aOne ; "one" 
call _puts 
jmp short locret_8048450 
loc_804841A: ; DATA XREF: .rodata:08048564 
mov [esp+18h+var_18], offset aTwo ; "two" 
call | puts 
jmp short locret 8048450 
loc 8048428: ; DATA XREF: .rodata:08048568 
mov [esp+18h+var 18], offset aThree ; "three" 
call puts 
jmp short locret 8048450 
loc 8048436: ; DATA XREF: .rodata:0804856C 
mov [esp+18h+var 18], offset aFour ; "four" 
call | puts 
jmp short locret 8048450 
loc 8048444: ; CODE XREF: f+A 
mov [esp+18h+var 18], offset aSomethingUnkno ; "something unknown" 
call | puts 
locret 8048450: ; CODE XREF: f+26 
; 434... 
leave 
retn 
f endp 
off 804855C dd offset loc 80483FE ; DATA XREF: f+12 


dd offset loc 804840C 
dd offset loc 804841A 
dd offset loc 8048428 
dd offset loc 8048436 


C'est presque la méme chose, avec une petite nuance: l'argument arg 0 est mul- 
tiplié par 4 en décalant de 2 bits vers la gauche (c'est presque comme multiplier 
par 4) (1.24.2 on page 284). Ensuite l'adresse du label est prise depuis le tableau 
off 804855C, stockée dans EAX, et ensuite JMP EAX effectue le saut réel. 


ARM: avec optimisation Keil 6/2013 (Mode ARM) 


Listing 1.159 : avec optimisation Keil 6/2013 (Mode ARM) 


00000174 f2 

00000174 05 00 50 E3 CMP RO, #5 ; Switch 5 cases 
00000178 00 F1 8F 30 ADDCC PC, PC, RO,LSLZ2 ; switch jump 
0000017C OE 00 00 EA B default case ; jumptable 00000178 


default case 


00000180 


00000180 
00000180 


00000184 
00000184 
00000184 


00000188 
00000188 
00000188 


0000018C 
0000018C 
0000018C 


00000190 
00000190 
00000190 


00000194 
00000194 
00000194 
00000194 
00000198 


0000019C 
0000019C 
0000019C 
0000019C 
000001A0 


000001A4 
000001A4 
000001A4 
000001A4 
000001A8 


000001AC 
000001AC 
000001AC 
000001AC 
000001B0 


000001B4 
000001B4 
000001B4 
000001B4 
000001B8 
000001B8 
000001B8 
000001B8 


000001BC 


03 


04 


05 


06 


07 


EC 
06 


EC 
04 


01 
02 


01 
00 


01 


66 


00 


00 


00 


00 


00 


00 
00 


00 
00 


OC 
00 


OC 
00 


OC 


18 


00 


00 


00 


00 


00 


8F 
00 


8F 
00 


8F 
00 


8F 
00 


8F 


00 


EA 


EA 


EA 


EA 


EA 


E2 
EA 


E2 


E2 
EA 


E2 


E2 


EA 


loc 180 
B 


loc 184 ; 
B 


loc 188 ; 
B 


loc 18C 
B 


loc 190 
B 


zero case ; 


ADR 
B 


one case ; 
ADR 


B 


two case ; 


CODE XREF: f2+4 


zero case 


CODE XREF: f2+4 


one case 


CODE XREF: f2+4 


two case 


CODE XREF: f244 


three case 


CODE XREF: f2+4 


, 


, 


four case 


CODE XREF: f244 
f2:loc 180 

RO, aZero 

loc 1B8 


CODE XREF: f2+4 
f2:loc 184 


RO, a0ne 
loc 1B8 


CODE XREF: f2+4 


; f2:loc 188 


ADR 
B 


three case ; 
; f2:loc 18C 


ADR 
B 


four case ; 


ADR 
loc 1B8 


B 


, 


RO, aTwo 
loc 1B8 


CODE XREF: f2+4 


RO, aThree 
loc 1B8 


CODE XREF: f244 
f2:loc 190 
RO, aFour 


CODE XREF: f2+24 
f242C 
_ 2printf 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


; jumptable 


00000178 


00000178 


00000178 


00000178 


00000178 


00000178 


00000178 


00000178 


00000178 


00000178 


case 1 


case 2 


case 3 


case 4 


case 0 


case 1 


case 2 


case 3 


case 4 
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000001BC default case ; CODE XREF: f2+4 

000001BC ; f2+8 

000001BC D4 00 8F E2 ADR RO, aSomethingUnkno ; jumptable 00000178 
default case 

| 990001C0 FC FF FF EA B loc 1B8 | 


Ce code utilise les caractéristiques du mode ARM dans lequel toutes les instructions 
ont une taille fixe de 4 octets. 


Gardons à l'esprit que la valeur maximale de a est 4 et que toute autre valeur supé- 
rieure provoquera l'affichage de la chaine «something unknown|n» 


La premiére instruction CMP RO, #5 compare la valeur entrée dans a avec 5. 


?8 l'instruction suivante, ADDCC PC, PC, RO,LSLZ2, est exécutée si et seulement si 
RO < 5 (CC=Carry clear / Less than retenue vide, inférieur à). Par conséquent, si ADDCC 
n'est pas exécutée (c'est le cas RO > 5), un saut au label default case se produit. 


Mais si R0 « 5 et que ADDCC est exécuté, voici ce qui se produit: 


La valeur dans RO est multipliée par 4. En fait, le suffixe de l'instruction LSL#2 signi- 
fie «décalage à gauche de 2 bits». Mais comme nous le verrons plus tard (1.24.2 
on page 284) dans la section «Décalages », décaler de 2 bits vers la gauche est 
équivalent à multiplier par 4. 


Puis, nous ajoutons RO + 4 à la valeur courante du PC, et sautons à l'une des instruc- 
tions B (Branch) situées plus bas. 


Au moment de l'exécution de ADDCC, la valeur du PC est en avance de 8 octets 
(0x180) sur l'adresse à laquelle l'instruction ADDCC se trouve (0x178), ou, autrement 
dit, en avance de 2 instructions. 


C'est ainsi que le pipeline des processeurs ARM fonctionne: lorsque ADDCC est exé- 
cutée, le processeur, à ce moment, commence à préparer les instructions aprés la 
suivante, c'est pourquoi PC pointe ici. Cela doit étre mémorisé. 


Si a = 0, elle sera ajoutée à la valeur de PC, et la valeur courante de PC sera écrite 
dans PC (qui est 8 octets en avant) et un saut au label /oc 180 sera effectué, qui est 
8 octets en avant du point ou l'instruction se trouve. 


Si a = 1, alors PC+8+ax*4=PC+8+1+*4= PC + 12 = 01184 sera écrit dans PC, qui 
est l'adresse du label loc 184. 


A chaque fois que l'on ajoute 1 à a, le PC résultant est incrémenté de 4. 


4 est la taille des instructions en mode ARM, et donc, la longueur de chaque instruc- 
tion B desquelles il y a 5 à la suite. 


Chacune de ces cinq instructions B passe le contróle plus loin, à ce qui a été pro- 
grammé dans le switch(). 


Le chargement du pointeur sur la chaine correspondante se produit ici, etc. 


98ADD—addition 


230 


ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.160 : avec optimisation Keil 6/2013 (Mode Thumb) 


000000F6 EXPORT f2 

000000F6 f2 

000000F6 10 B5 PUSH {R4, LR} 

000000F8 03 00 MOVS R3, RO 

000000FA 06 FO 69 F8 BL . ARM common switch8 thumb ; switch 6 
cases 

000000FE 05 DCB 5 

000000FF 04 06 08 OA OC 10 DCB 4, 6, 8, OxA, OxC, 0x10 ; jump table for 
switch statement 

00000105 00 ALIGN 2 

00000106 

00000106 zero case ; CODE XREF: f2+4 

00000106 8D A0 ADR RO, aZero ; jumptable 000000FA case 0 

00000108 06 EO B loc 118 

0000010A 

0000010A one case ; CODE XREF: f2+4 

0000010A 8E AO ADR RO, a0ne ; jumptable 000000FA case 1 

0000010C 04 EO B loc 118 

0000010E 

0000010E two case ; CODE XREF: f2+4 

0000010E 8F AO ADR RO, aTwo ; jumptable 000000FA case 2 

00000110 02 EO B loc 118 

00000112 

00000112 three case ; CODE XREF: f2+4 

00000112 90 A0 ADR RO, aThree ; jumptable 000000FA case 3 

00000114 00 EO B loc 118 

00000116 

00000116 four case ; CODE XREF: f2+4 

00000116 91 A0 ADR RO, aFour ; jumptable 000000FA case 4 

00000118 

00000118 loc 118 ; CODE XREF: f2+12 

00000118 ; f2+16 

00000118 06 FO 6A F8 BL . 2printf 

0000011C 10 BD POP {R4, PC} 

0000011E 

0000011E default case ; CODE XREF: f2+4 

deren 82 A0 ADR RO, aSomethingUnkno ; jumptable 

00000FA petant case 

00000120 FA E B loc 118 

000061D0 EXPORT . ARM common switch8 thumb 

000061D0 . ARM common switch8 thumb ; CODE XREF: 


example6 f2+4 
000061D0 78 47 BX PC 
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000061D2 00 00 ALIGN 4 

000061D2 ; End of function ARM common switch8 thumb 

000061D2 

000061D4 32 ARM common switch8 thumb ; CODE XREF: 
ARM common switch8 thumb 

000061D4 01 CO 5E E5 LDRB R12, [LR,£-1] 

000061D8 OC 00 53 El CMP R3, R12 

000061DC OC 30 DE 27 LDRCSB R3, [LR,R12] 

000061E0 03 30 DE 37 LDRCCB R3, [LR,R3] 

000061E4 83 CO 8E EO ADD R12, LR, R3,LSL#1 

000061E8 1C FF 2F El BX R12 

000061E8 ; End of function 32 ARM common switch8 thumb 


On ne peut pas étre sür que toutes ces instructions en mode Thumb et Thumb-2 
ont la méme taille. On peut méme dire que les instructions dans ces modes ont une 
longueur variable, tout comme en x86. 


Donc, une table spéciale est ajoutée, qui contient des informations sur le nombre de 
cas (sans inclure celui par défaut), et un offset pour chaque label auquel le contróle 
doit étre passé dans chaque cas. 


Une fonction spéciale est présente ici qui s'occupe de la table et du passage du 
contróle, appelée 

. ARM common switch8 thumb. Elle commence avec BX PC, dont la fonction est 
de passer le mode du processeur en ARM. Ensuite, vous voyez la fonction pour le 
traitement de la table. 


C'est trop avancé pour étre détaillé ici, donc passons cela. 


Il est intéressant de noter que la fonction utilise le registre LR comme un pointeur 
sur la table. 


En effet, aprés l'appel de cette fonction, LR contient l'adresse aprés l'instruction 
BL _ ARM common switch8 thumb, où la table commence. 


Il est intéressant de noter que le code est généré comme une fonction indépendante 
afin de la ré-utiliser, donc le compilateur ne générera pas le méme code pour chaque 
déclaration switch(). 


IDA l'a correctement identifié comme une fonction de service et une table, et a ajouté 
un commentaire au label comme jumptable 000000FA case 0. 


MIPS 


Listing 1.161 : GCC 4.4.5 avec optimisation (IDA) 


lui $gp, ( gnu local gp >> 16) 
; sauter en loc 24 si la valeur entrée est plus petite que 5: 
sltiu $vO, $a0, 5 
bnez $v0, loc 24 
la $gp, ( gnu local gp € OxFFFF) ; slot de délai de 


branchement , n , . 
; la valeur entrée est supérieur ou égale à 5. 


; afficher "something unknown" et terminer: 
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lui 
lw 
or 
jr 
la 


loc 24: 


$a0, ($LC5 >> 16) # "something unknown" 
$t9, (puts € OxFFFF) ($gp) 
$at, $zero ; NOP 
$t9 
$a0, ($LC5 € OxFFFF) £ "something unknown" 
; Slot de délai de branchement 


# CODE XREF: f+8 


; charger l'adresse de la table de branchement/saut 
; LA est une pseudo instruction, il s'agit en fait de LUI et ADDIU: 


la 


sll 


$vO, off 120 


multiplier la valeur entrés par 4: 


$a0, 2 


ajouter la valeur multipliée et l'adresse de la table de saut: 
addu 
charger l'élément de la table de saut: 


$a0, $v0, $a0 


$v0, 0($a0) 
$at, $zero ; NOP 


; sauter à l'adresse que nous avons dans la table de saut: 


$v0 
$at, $zero ; slot de délai de branchement, NOP 


# DATA XREF: .rodata:0000012C 


et terminer 


$20, ($LC3 >> 16) # "three" 

$t9, (puts € OxFFFF) ($gp) 

$at, $zero ; NOP 

$t9 

$20, ($LC3 € OXFFFF) # "three" ; slot de délai de 


# DATA XREF: .rodata:00000130 
$20, ($LC4 >> 16) # "four" 

$t9, (puts € OxFFFF) ($gp) 

$at, $zero ; NOP 

$t9 

$a0, ($LC4 € OXFFFF) # "four" ; slot de délai de 


# DATA XREF: .rodata:off 120 
$a0, ($LCO >> 16) # "zero" 

$t9, (puts € OxFFFF) ($gp) 

$at, $zero ; NOP 

$t9 

$a0, ($LCO € OXFFFF) # "zero" ; slot de délai de 


# DATA XREF: .rodata:00000124 


$a0, ($LC1 >> 16) # "one" 
$t9, (puts & OxFFFF) ($gp) 


lw 

or 

jr 

or 
sub_44: 

; afficher "three" 
lui 
lw 
or 
jr 
la 

branchement 
sub_58: 

; afficher "four" et terminer 
lui 
lw 
or 
jr 
la 

branchement 
sub_6C: 

; afficher "zero" et terminer 
lui 
lw 
or 
jr 
la 

branchement 
sub_80: 

; afficher "one" et terminer 
lui 
lw 
or 


gat, $zero ; NOP 
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jr $t9 
la $a0, ($LC1 € OXFFFF) # "one" ; slot de délai de 
branchement 
sub 94: # DATA XREF: .rodata:00000128 
; afficher "two" et terminer 
lui $a0, ($LC2 >> 16) # "two" 
lw $t9, (puts & OxFFFF) ($gp) 
or $at, $zero ; NOP 
jr $t9 
la $20, ($LC2 € OXFFFF) £ "two" ; slot de délai de 
branchement 


; peut étre mis dans une section .rodata: 
off 120: .word sub 6C 

.word sub 80 

.word sub 94 

.word sub 44 

.word sub 58 


La nouvelle instruction pour nous est SLTIU («Set on Less Than Immediate Unsi- 
gned » Mettre si inférieur à la valeur immédiate non signée). 


Ceci est la méme que SLTU («Set on Less Than Unsigned »), mais «l» signifie «im- 
mediate », i.e., un nombre doit étre spécifié dans l'instruction elle-méme. 


BNEZ est «Branch if Not Equal to Zero ». 


Le code est trés proche de l'autre ISAs. SLL («Shift Word Left Logical ») effectue une 
multiplication par 4. 


MIPS est un CPU 32-bit aprés tout, donc toutes les adresses de la jumtable sont 
32-bits. 

Conclusion 

Squelette grossier d'un switch() : 


Listing 1.162 : x86 


MOV REG, input 

CMP REG, 4 ; nombre maximal de cas 

JA default 

SHL REG, 2 ; trouver l'élément dans la table. décaler de 3 bits en x64. 
MOV REG, jump table[REG] 

JMP REG 


casel: 
; faire quelque chose 
JMP exit 

case2: 
; faire quelque chose 
JMP exit 

case3: 
; faire quelque chose 
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JMP exit 
case4: 


; faire quelque chose 


JMP exit 
case5: 


; faire quelque chose 


JMP exit 


default: 


exit: 


jump_table dd casel 


dd 
dd 
dd 
dd 


case2 
case3 
case4 
case5 


Le saut a une 


adresse de la table de saut peut aussi étre implémenté en utilisant 
cette instruction: 
JMP jump table[REG*4]. Ou JMP jump table[REG*8] en x64. 


Une table de saut est juste un tableau de pointeurs, comme celle décrite plus loin: 
1.26.5 on page 364. 


1.21.3 Lorsqu'il y a quelques déclarations case dans un bloc 


Voici une construction trés répandue: quelques déclarations case pour un seul bloc: 


#include <stdio.h> 


void f(int a) 

{ 
switc 
{ 
case 
case 
case 
case 


case 
case 
case 
case 


case 
case 


h 


am BW 


1 
2: 
7: 
1 


(a) 


0: 
printf ("1, 2, 7, 10\n"); 
break; 


printf ("3, 4, 5\n"); 
break; 
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case 20: 
case 21: 
case 22: 
default: 
un 

Fi 

int main() 

{ 
f(4); 


printf ("8, 9, 21\n"); 
break; 


printf ("22\n"); 
break; 


printf ("default\n"); 
break; 


C'est souvent du gaspillage de générer un bloc pour chaque cas possible, c'est pour- 
quoi ce qui se fait d'habitude, c'est de générer un bloc et une sorte de répartiteur. 


MSVC 
Listing 1.163 : MSVC 2010 avec optimisation 
$SG2798 DB '1, 2, 7, 10', 0aH, OOH 
$SG2800 DB '3, 4, 5', 0aH, 00H 
$SG2802 DB '8, 9, 21', 0aH, OOH 
$SG2804 DB '22', 0aH, OOH 
$5G2806 DB 'default', OaH, 00H 
_a$ = 8 
f PROC 
mov eax, DWORD PTR _a$[esp-4] 
dec eax 
cmp eax, 21 
ja SHORT $LN1@f 
movzx eax, BYTE PTR $LN10@f [eax] 
jmp DWORD PTR $LN11@f [eax*4] 
$LN5@f : 
mov DWORD PTR _a$[esp-4], OFFSET $SG2798 ; ‘1, 2, 7, 10' 
jmp DWORD PTR _imp_ printf 
$LN4@f : 
mov DWORD PTR _a$[esp-4], OFFSET $SG2800 ; '3, 4, 5' 
jmp DWORD PTR __imp_ printf 
$LN3Qf : 
mov DWORD PTR a$[esp-4], OFFSET $SG2802 ; ‘8, 9, 21' 
jmp DWORD PTR _imp_ printf 
$LN2@f : 
mov DWORD PTR a$[esp-4], OFFSET $SG2804 ; '22' 
jmp DWORD PTR imp printf 
$LN1@f : 
mov DWORD PTR a$[esp-4], OFFSET $SG2806 ; ‘default’ 


236 


jmp DWORD PTR _ imp _ printf 
npad 2 ; aligner la table $LN11@f sur une limite de 16-octet 
$LN11@f : 


DD $LN5@f ; afficher '1, 2, 7, 10' 

DD $LNAGf ; afficher '3, 4, 5' 

DD $LN3Gf ; afficher '8, 9, 21' 

DD $LN2@f ; afficher '22' 

DD $LN1laGf ; afficher 'default' 
$LN10@fF : 

DB 0; a=1 

DB 0; a=2 

DB 145-323 

DB 1; a=4 

DB Ll $35 

DB 1; a=6 

DB 0 ; a=7 

DB 2 ; a=8 

DB 2 ; a=9 

DB 0 ; a=10 

DB 4 ; a=11 

DB 4 ; a=12 

DB 4 ; a=13 

DB 4 ; a=14 

DB 4 ; a=15 

DB 4 ; a=16 

DB 4 ; a=17 

DB 4 ; a=18 

DB 4 ; a=19 

DB 2 ; a=20 

DB 2 ; a=21 

DB 3 ; a=22 
f ENDP 


Nous voyons deux tables ici: la première ($LN10@f) est une table d'index, et la se- 
conde ($LN11@f) est un tableau de pointeurs sur les blocs. 


Tout d'abord, la valeur entrée est utilisée comme un index dans la table d'index 
(ligne 13). 


Voici un petit récapitulatif pour les valeurs dans la table: O est le premier bloc case 
(pour les valeurs 1, 2, 7, 10), 1 est le second (pour les valeurs 3, 4, 5), 2 est le 
troisieme (pour les valeurs 8, 9, 21), 3 est le quatriéme (pour la valeur 22), 4 est 
pour le bloc par défaut. 


Ici, nous obtenons un index pour la seconde table de pointeurs sur du code et nous 
y sautons (ligne 14). 


Il est intéressant de remarquer qu'il n'y a pas de cas pour une valeur d'entrée de 0. 


C'est pourquoi nous voyons l'instruction DEC à la ligne 10, et la table commence à 
a = 1, car il n'y a pas besoin d'allouer un élément dans la table pour a — 0. 


C'est un pattern trés répandu. 


Donc, pourquoi est-ce que c'est économique ? Pourquoi est-ce qu'il n'est pas possible 
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de faire comme avant (1.21.2 on page 226), avec une seule table consistant en des 
pointeurs vers les blocs? La raison est que les index des éléments de la table sont 
8-bit, donc c'est plus compact. 


GCC 


GCC génére du code de la facon dont nous avons déjà discuté (1.21.2 on page 226), 
en utilisant juste une table de pointeurs. 


ARM64: GCC 4.9.1 avec optimisation 


Il n'y a pas de code à exécuter si la valeur entrée est 0, c'est pourquoi GCC essaye de 
rendre la table des sauts plus compacte et donc il commence avec la valeur d'entrée 
1. 


GCC 4.9.1 pour ARM64 utilise un truc encore plus astucieux. ll est capable d'encoder 
tous les offsets en octets 8-bit. 


Rappelons-nous que toutes les instructions ARM64 ont une taille de 4 octets. 


GCC utilise le fait que tous les offsets de mon petit exemple sont tous proche l'un 
de l'autre. Donc la table des sauts consiste en de simple octets. 


Listing 1.164 : avec optimisation GCC 4.9.1 ARM64 


f14: 
; valeur entrée dans WO 
sub w0, w0, #1 
cmp w0, 21 
; branchement si inférieur ou égal (non signé): 
bls .L9 
.L2: 
; afficher "default": 
adrp x0, .LC4 
add x0, x0, :lo12:.LC4 
b puts 
.L9: 
; charger l'adresse de la table des sauts dans X1: 
adrp x1, .L4 
add x1, x1, :lo12:.L4 
WO-input value-1 
charger un octet depuis la table: 
ldrb w0, [x1,w0,uxtw] 
charger l'adresse du label .Lrtx4: 
adr x1, .Lrtx4 
multiplier l'élément de la table par 4 (en décalant de 2 bits à gauche) et 
ajouter (ou soustraire) à l'adresse de .Lrtx4: 


add x0, x1, w0, sxtb #2 
; sauter à l'adresse calculée: 
br x0 
; ce label pointe dans le segment de code (text): 


.Lrtx4: 
.section .rodata 
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; tout ce qui se trouve aprés la 


segment de données 
; en lecture seule (rodata): 
.L4: 


.byte (.L3 - .Lrtx4) 
.byte (.L3 - .Lrtx4) 
.byte (.L5 - .Lrtx4) 
.byte (.L5 - .Lrtx4) 
.byte (.L5 - .Lrtx4) 
.byte (.L5 - .Lrtx4) 
.byte (.L3 - .Lrtx4) 
.byte (.L6 - .Lrtx4) 
.byte (.L6 - .Lrtx4) 
.byte (.L3 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L2 - .Lrtx4) 
.byte (.L6 - .Lrtx4) 
.byte (.L6 - .Lrtx4) 
.byte (.L7 - .Lrtx4) 
. text 


; tout ce qui se trouve aprés la 


segment de code (text): 
.L7: 


; afficher "22" 
adrp x0, .LC3 
add x0, x0, :lo12: 
b puts 

.L6: 

; afficher "8, 9, 21" 
adrp x0, .LC2 
add x0, x0, :lo12: 
b puts 

.L5: 

; afficher "3, 4, 5" 
adrp x0, .LC1 
add x0, x0, :lo12: 
b puts 

.L3: 

; afficher "1, 2, 7, 10" 
adrp x0, .LCO 
add x0, x0, :lo12: 
b puts 

.LC0: 


.string "1, 2, 7, 10" 
.LC1: 

.string "3, 4, 5" 
.LC2: 


DoS 
PHHPHHHHAPHAHHHPHPAHPHHHPAHAHAAHA 


.LC3 


.LC2 


.LC1 


.LCO 


déclaration 


case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 
case 


déclaration 


" section" 
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"text" 


est alloué dans le 


est alloué dans le 
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.string "8, 9, 21" 
.LC3: 

.string "22" 
.LC4: 

.string "default" 


Compilons cet exemple en un fichier objet et ouvrons-le dans IDA. Voici la table des 
sauts: 


Listing 1.165 : jumptable in IDA 


.rodata:0000000000000064 AREA .rodata, DATA, READONLY 
. rodata:0000000000000064 ; ORG 0x64 
.rodata:0000000000000064 $d DCB 9 ; case 1 
.rodata:0000000000000065 DCB 9 ; case 2 
. rodata:0000000000000066 DCB 6 ; case 3 
. rodata:0000000000000067 DCB 6 ; case 4 
. rodata:0000000000000068 DCB 6 ; case 5 
. rodata:0000000000000069 DCB 6 ; case 6 
.rodata:000000000000006A DCB 9 ; case 7 
.rodata:000000000000006B DCB 3 ; case 8 
.rodata:000000000000006C DCB 3 ; case 9 
. rodata:000000000000006D DCB 9 ; case 10 
.rodata:000000000000006E DCB 0xF7 ; case 11 
.rodata:000000000000006F DCB 0xF7 ; case 12 
.rodata:0000000000000070 DCB 0xF7 ; case 13 
. rodata:0000000000000071 DCB 0xF7 ; case 14 
.rodata:0000000000000072 DCB 0xF7 ; case 15 
.rodata:0000000000000073 DCB 0xF7 ; case 16 
.rodata:0000000000000074 DCB 0xF7 ; case 17 
. rodata:0000000000000075 DCB 0xF7 ; case 18 
.rodata:0000000000000076 DCB 0xF7 ; case 19 
.rodata:0000000000000077 DCB 3 ; case 20 
.rodata:0000000000000078 DCB 3 ; case 21 
. rodata:0000000000000079 DCB 0 ; case 22 
.Fodata:000000000000007B ; .rodata ends 


Donc dans le cas de 1, 9 est multiplié par 4 et ajouté à l'adresse du label Lrtx4. 
Dans le cas de 22, 0 est multiplié par 4, ce qui donne 0. 
Juste aprés le label Lrtx4 se trouve le label L7, oü se trouve le code qui affiche «22 ». 


Il n'y a pas de table des sauts dans le segment de code, elle est allouée dans la 
section .rodata (il n'y a pas de raison de l'allouer dans le segment de code). 


Il y a aussi des octets négatifs (OxF7), ils sont utilisés pour sauter en arriére dans le 
code qui affiche la chaine «default» (en .L2). 
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1.21.4 Fall-through 


Un autre usage trés répandu de l'opérateur switch() est ce qu'on appelle un «fall- 
through » (passer à travers). Voici un exemple simple?? : 


bool is whitespace(char c) { 
switch (c) 4 
case ' ': // fallthrough 
case 'Nt': // fallthrough 
case '\r': // fallthrough 
case ‘\n': 
return true; 
default: // not whitespace 
return false; 


} 


Légérement plus difficile, tiré du noyau Linux?” : 


char ncol, nco2; 


void f(int if freq khz) 
1 


switch (if freq khz) { 
default: 
printf("IF=%d KHz is not supportted, 3250 assumed\n” 
V ", if freq khz); 
/* fallthrough */ 
case 3250: /* 3.25Mhz */ 


ncol - 0x34; 
nco2 = 0x00; 
break; 

case 3500: /* 3.50Mhz */ 
ncol = 0x38; 
nco2 - 0x00; 
break; 

case 4000: /* 4.00Mhz */ 
ncol - 0x40; 
nco2 - 0x00; 
break; 

case 5000: /* 5.00Mhz */ 
ncol = 0x50; 
nco2 - 0x00; 
break; 

case 5380: /* 5.38Mhz */ 
ncol = 0x56; 
nco2 - 0x14; 
break; 


) 


39Copié/collé depuis https://github.com/azonalon/prgraas/blob/master/progllib/lecture 
examples/is whitespace.c 

100Copié/collé depuis https://github.com/torvalds/linux/blob/master/drivers/media/ 
dvb- frontends/lgdt3306a.c 
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}; 
Listing 1.166 : GCC 5.4.0 x86 avec optimisation 
.LC0: 
.string "IF=%d KHz is not supportted, 3250 assumed ^n" 
f: 
sub esp, 12 
mov eax, DWORD PTR [esp+16] 
cmp eax, 4000 
je .L3 
jg .L4 
cmp eax, 3250 
je .L5 
cmp eax, 3500 
jne .L2 
mov BYTE PTR ncol, 56 
mov BYTE PTR nco2, 0 
add esp, 12 
ret 
.L4: 
cmp eax, 5000 
je .L7 
cmp eax, 5380 
jne .L2 
mov BYTE PTR ncol, 86 
mov BYTE PTR nco2, 20 
add esp, 12 
ret 
.L2: 
sub esp, 8 
push eax 
push OFFSET FLAT:.LCO 
call printf 
add esp, 16 
.L5: 
mov BYTE PTR ncol, 52 
mov BYTE PTR nco2, 0 
add esp, 12 
ret 
.L3: 
mov BYTE PTR ncol, 64 
mov BYTE PTR nco2, 0 
add esp, 12 
ret 
.L7: 
mov BYTE PTR ncol, 80 
mov BYTE PTR nco2, 0 
add esp, 12 
ret 


Nous atteignons le label .L5 si la fonction a recue le nombre 3250 en entrée. Mais 
nous pouvons atteindre ce label d'une autre façon: nous voyons qu'il n'y a pas de 
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saut entre l'appel à printf () et le label .L5. 


Nous comprenons maintenant pourquoi la déclaration switch() est parfois une source 
de bug: un break oublié va transformer notre déclaration switch() en un fallthrough, 
et plusieurs blocs seront exécutés au lieu d'un seul. 


1.21.5 Exercices 
Exercice#1 


Il est possible de modifier l'exemple en C de 1.21.2 on page 220 de telle sorte que 
le compilateur produise un code plus concis, mais qui fonctionne toujours pareil. 


1.22 Boucles 


1.22.1 Exemple simple 
x86 


Il y a une instruction LOOP spéciale en x86 qui teste le contenu du registre ECX et 
si il est différent de 0, le décrémente et continue l'exécution au label de l'opérande 
LOOP. Probablement que cette instruction n'est pas trés pratique, et il n'y a aucun 
compilateur moderne qui la génére automatiquement. Donc, si vous la rencontrez 
dans du code, il est probable qu'il s'agisse de code assembleur écrit manuellement. 


En C/C++ les boucles sont en général construites avec une déclaration for(), while() 
ou do/while(). 


Commencons avec for(). 


Cette déclaration définit l'initialisation de la boucle (met le compteur á sa valeur ini- 
tiale), la condition de boucle (est-ce que le compteur est plus grand qu'une limite?), 
qu'est-ce qui est fait à chaque itération (incrémenter/décrémenter) et bien sûr le 
corps de la boucle. 


for (initialisation; condition; à chaque itération) 


{ 
I 


corps de la boucle; 


Le code généré consiste également en quatre parties. 


Commengons avec un exemple simple: 


#include <stdio.h> 


void printing function(int i) 


{ 

printf ("f(%d)\n", i); 
}; 
int main() 


{ 
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int i; 


for (i22; i«10; i++) 
printing function(i); 


return 0; 


Résultat (MSVC 2010) : 
Listing 1.167 : MSVC 2010 


i$ = -4 
main PROC 
push ebp 
mov ebp, esp 
push ecx 
mov DWORD PTR i$[ebp], 2 ; initialiser la boucle 
jmp SHORT $LN3@main 
$LN2@main: 
mov eax, DWORD PTR i$[ebp] ; ici se trouve ce que nous faisons après 
chaque itération: 
add eax, 1 ; ajouter 1 à la valeur de (i) 
mov DWORD PTR i$[ebp], eax 
$LN3@main: 
cmp DWORD PTR i$[ebp], 10 ; cette condition est testée avant chaque 
itération d ; : 
jge SHORT $LN1@main ; Si (i) est supérieur ou égal à 10, la 


boucle se termine : 
mov ecx, DWORD PTR i$[ebp] ; corps de la boucle: appel de 


printing function(i) 


push ecx 

call printing function 

add esp, 4 

jmp SHORT $LN2@main ; saut au début de la boucle 
$LN1@main: ; fin de la boucle 

xor eax, eax 

mov esp, ebp 

pop ebp 

ret 0 
_main ENDP 


Comme nous le voyons, rien de spécial. 


GCC 4.4.1 génére presque le méme code, avec une différence subtile: 


Listing 1.168 : GCC 4.4.1 


main proc near 
var 20 - dword ptr -20h 
var 4 - dword ptr -4 
push ebp 
mov ebp, esp 


and esp, OFFFFFFFOh 
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sub esp, 20h 
mov [esp+20h+var 4], 2 ; initialiser (i) 
jmp short loc_8048476 
loc_8048465: 
mov eax, [esp+20h+var 4] 
mov [esp+20h+var 20], eax 
call printing function 
add [esp+20h+var_ 4], 1 ; incrémenter (i) 
loc 8048476: 
cmp [esp+20h+var_4], 9 
jte short loc 8048465 ; Si i«-9, continuer la boucle 
mov eax, 0 
leave 
retn 
main endp 


Maintenant, regardons ce que nous obtenons avec l'optimisation (/0x) : 


Listing 1.169 : avec optimisation MSVC 


main PROC 
push esi 
mov esi, 2 
$LL3@main: 
push esi 
call printing function 
inc esi 
add esp, 4 
cmp esi, 10 ; 0000000aH 
jl SHORT $LL3@main 
xor eax, eax 
pop esi 
ret 0 
_main ENDP 


Ce qui se passe alors, c'est que l'espace pour la variable i n'est plus alloué sur la 
pile locale, mais utilise un registre individuel pour cela, ESI. Ceci est possible pour 
ce genre de petites fonctions, oü il n'y a pas beaucoup de variables locales. 


Il est très important que la fonction f () ne modifie pas la valeur de ESI. Notre com- 
pilateur en est sür ici. Et si le compilateur décide d'utiliser le registre ESI aussi dans 
la fonction f (), sa valeur devra être sauvegardée lors du prologue de la fonction et 
restaurée lors de son épilogue, presque comme dans notre listing: notez les PUSH 
ESI/POP ESI au début et à la fin de la fonction. 


Essayons GCC 4.4.1 avec l'optimisation la plus performante (option -03) : 


Listing 1.170 : GCC 4.4.1 avec optimisation 


main proc near 


var 10 - dword ptr -10h 
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push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 10h 
mov [esp+10h+var_ 10], 2 
call printing function 
mov [esp+10h+var_ 10], 3 
call printing function 
mov [esp+10h+var 10], 4 
call printing function 
mov [esp+10h+var_10], 5 
call printing function 
mov [esp+10h+var_10], 6 
call printing function 
mov [esp+10h+var_10], 7 
call printing function 
mov [esp+10h+var_10], 8 
call printing function 
mov [esp+10h+var_10], 9 
call printing function 
xor eax, eax 
leave 
retn 

main endp 


Hé, GCC a juste déroulé notre boucle. 


Le déroulement de boucle est un avantage lorsqu'il n'y a pas beaucoup d'itérations 
et que nous pouvons économiser du temps d'exécution en supprimant les instruc- 
tions de gestion de la boucle. D'un autre cóté, le code est étonnement plus gros. 


Dérouler des grandes boucles n'est pas recommandé de nos jours, car les grosses 
fonctions ont une plus grande empreinte sur le cache!?!, 


Ok, augmentons la valeur maximale de la variable i à 100 et essayons à nouveau. 
GCC donne: 


Listing 1.171 : GCC 


public main 


main proc near 

var 20 = dword ptr -20h 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
push ebx 
mov ebx, 2 ; 1=2 
sub esp, 1Ch 


101Un trés bon article à ce sujet: [Ulrich Drepper, What Every Programmer Should Know About Memory, 
(2007)]102. D'autres recommandations sur l'expansion des boucles d'Intel sont ici: [Intel® 64 and IA-32 
Architectures Optimization Reference Manual, (2014)3.4.1.7]. 
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; aligner le label loc 80484D0 (début du corps de la boucle) sur une limite 


de 16-octet: 
nop 


loc 80484D0: 


; passer (i) comme premier argument à printing function(): 


mov 
add 
call 
cmp 
jnz 
add 
xor 
pop 
mov 
pop 
retn 
main endp 


[esp+20h+var 20], ebx 

ebx, 1 ; i++ 

printing_function 

ebx, 64h ; i==100? 

short loc 80484D0 ; si non, continuer 
esp, 1Ch 

eax, eax ; renvoyer 0 

ebx 

esp, ebp 

ebp 


C'est assez similaire à ce que MSVC 2010 génère avec l'optimisation (/0x), avec 
l'exception que le registre EBX est utilisé pour la variable ;. 


GCC est sûr que ce registre ne sera pas modifié à l'intérieur de la fonction f (), et si 
il l'était, il serait sauvé dans le prologue de la fonction et restauré dans l'épilogue, 
tout comme dans la fonction main(). 
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x86: OllyDbg 


Compilons notre exemple dans MSVC 2010 avec les options /0x et /0b0, puis char- 
geons le dans OllyDbg. 


Il semble qu'OllyDbg soit capable de détecter des boucles simples et les affiche entre 
parenthéses, par commodité. 


a83128R8 
C SALUE 


6 
C200686S BB24FD18 


31 ; 
D4FFFFFF || CALL oops 2.00951000 SS ODA 


ADD ESP, 4 00333378 
CMP ESI, OA ' 00331020 


JL SHORT loops_2. 00231026 
XOR EAX, EAX 
POP ESI 


RETN 
PUSH loops_2.00331406 


-ornm Doo 


DOS Dro 


oo 


Fig. 1.54: OllyDbg : début de main() 


En tracant (F8 — enjamber) nous voyons ESI s'incrémenter. Ici, par exemple, ESI — 
i=6: 


CPU - main thread, module loops_2 


INT3 
6 PUSH ESI 
62690606  |MOU ESI,2 
PUSH ESI 
D4FFFFFF CALL loops_2. 00331000 
INC ESI 
ADD ESP,4 
CMP _ESI, GA 
JL SHORT loops_2. 00331026 
XOR EAX, EAX 
POP ESI 


ETN 
PUSH Loops. 2.88331486 


Fig. 1.55: OllyDbg : le corps de la boucle vient de s'exécuter avec i — 6 


9 est la derniére valeur de la boucle. C'est pourquoi JL ne s'exécute pas aprés 
l'incrémentation, et que le fonction se termine. 


6 
02000000 


D4FFFFFF 
INC ESI 

ADD ESP,4 
CMP E 


OP ESI 
RETN 


x86: tracer 


z . SE Pi 
a39| . PUSH Loops. Ea 
ES a 


Fig. 1.56: OllyDbg : EST = 10, fin de la boucle 


H ESI 
CALL loops_2. 00331000 


SI 8 
JL SHORT loops_2. 00331026 
NOR ERX, EAX 


2. 00331406 
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CPU - main thread, module loops_2 


LastErr ERROF 


Comme nous venons de le voir, il n'est pas tres commode de tracer manuellement 
dans le débogueur. C'est pourquoi nous allons essayer tracer. 


Nous ouvrons dans IDA l'exemple compilé, trouvons l'adresse de l'instruction PUSH 
ESI (qui passe le seul argument à f ( )), qui est 0x401026 dans ce cas et nous lançons 


le tracer : 


tracer.exe -l:loops 2.exe bpx=loops_2.exe!0x00401026 


BPX met juste un point d'arrêt à l'adresse et tracer va alors afficher l'état des re- 


gistres. 


Voici ce que l'on voit dans tracer. log : 


PID=12884|New process loops 2. 
(0) loops_2.exe!0x401026 
EAX=0x00a328c8 EBX=0x00000000 
ESI=0x00000002 EDI=0x00333378 
EIP=0x00331026 

FLAGS=PF ZF IF 

(0) loops_2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000003 EDI=0x00333378 
EIP=0x00331026 

FLAGS=CF PF AF SF IF 

(0) loops_2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000004 EDI=0x00333378 
EIP=0x00331026 

FLAGS=CF PF AF SF IF 

(0) loops_2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000005 EDI=0x00333378 
EIP=0x00331026 


exe 


ECX-0x6f0f4714 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


EDX=0x00000000 
ESP=0x0024fbb8 


EDX=0x000ee188 
ESP=0x0024 fbb8 


EDX=0x000ee188 
ESP=0x0024 fbb8 


EDX=0x000ee188 
ESP=0x0024 fbb8 


249 


FLAGS=CF AF SF IF 

(0) loops 2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000006 EDI=0x00333378 
EIP-0x00331026 

FLAGS-CF PF AF SF IF 

(0) loops 2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000007 EDI=0x00333378 
EIP-0x00331026 

FLAGS-CF AF SF IF 

(0) loops 2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000008 EDI=0x00333378 
EIP-0x00331026 

FLAGS-CF AF SF IF 

(0) loops 2.exe!0x401026 
EAX=0x00000005 EBX=0x00000000 
ESI=0x00000009 EDI=0x00333378 
EIP-0x00331026 

FLAGS=CF PF AF SF IF 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


ECX=0x6f0a5617 
EBP=0x0024fbfc 


EDX=0x000ee188 
ESP=0x0024fbb8 


EDX=0x000ee188 
ESP=0x0024 fbb8 


EDX=0x000ee188 
ESP=0x0024fbb8 


EDX=0x000ee188 
ESP=0x0024fbb8 


PID=12884|Process loops 2.exe exited. ExitCode=0 (0x0) 


Nous voyons comment la valeur du registre ESI change de 2 à 9. 


Encore plus que ca, tracer peut collecter les valeurs des registres pour toutes les 
adresses dans la fonction. C'est appelé trace ici. Chaque instruction esttracée, toutes 
les valeurs intéressantes des registres sont enregistrées. 


Ensuite, un script IDA .idc est généré, qui ajoute des commentaires. Donc, dans 
IDA, nous avons appris que l'adresse de la fonction main() est 0x00401020 et nous 
lancons: 


tracer.exe -l:loops 2.exe bpf=loops 2.exe!0x00401020, trace:cc 


BPF signifie mettre un point d'arrét sur la fonction. 


Comme résultat, nous obtenons les scripts Loops 2.exe.idcetloops 2.exe clear.idc. 
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Nous chargeons loops 2.exe.idc dans IDA et voyons: 


-text: 

-text: y =============== S i B R O U T I N E =s2sssssssssssssssssssssssssssssssss==s 
-text: 

-text: 

-text: ; int _ cdecl main(int argc, const char **argu, const char **enup) 

-text: .nai proc near ; CODE XREF: ___tmainCRTStartup+11DJp 
.text: 

.text: = dword ptr 4 

-text: = dword ptr 8 


.text: 


dword ptr  8Ch 
.text: 

-text: push esi ; ESI=1 
-text : 66491621 mou esi, 2 
-text : 00401026 

-text: 66461626 loc_4101626: 


CODE XREF: _main+134j 


, 
.text: 00401026 push esi ; ESI-2..9 
.text:00401027 Call sub_461666 H tracing nested maximum leuel (1) reached, 
-text : 66461620 inc esi ; ESI-2..9 
.text:0040102D add esp, 4 ; ESP-8x38fcbc 
. text : 66461636 cmp esi, 6Ah 3 ESI=3..6xa 
-text : 66461633 jl short loc 401826 ; SF=false,true OF=false 
-text : 66461635 xor eax, eax 
-text : 66401637 pop esi 
-text : 66461638 retn ; EAX=6 
.text:00401038 main endp 


Fig. 1.57: IDA avec le script .idc chargé 


Nous voyons que ESI varie de 2 à 9 au début du corps de boucle, mais de 3 à OxA 
(10) aprés l'incrément. Nous voyons aussi que main() se termine avec 0 dans EAX. 


tracer génére également loops 2.exe.txt, qui contient des informations sur le 
nombre de fois qu'une instruction a été exécutée et les valeurs du registre: 


Listing 1.172 : loops 2.exe.txt 


0x401020 (.text+0x20), e- 1 [PUSH ESI] ESI-1 

0x401021 (.text+0x21), e- 1 [MOV ESI, 2] 

0x401026 (.text+0x26), e= 8 [PUSH ESI] ESI=2..9 

0x401027 (.text+0x27), e- 8 [CALL 8D1000h] tracing nested maximum 2 
V level (1) reached, skipping this CALL 8D1000h=0x8d1000 

0x40102c (.text+0x2c), e= 8 [INC ESI] ESI=2..9 

0x40102d (.text+0x2d), e- 8 [ADD ESP, 4] ESP=0x38fcbc 

0x401030 (.text+0x30), e= 8 [CMP ESI, 0Ah] ESI=3..0xa 

0x401033 (.text+0x33), e- 8 [JL 8D1026h] SF=false,true OF=false 

0x401035 (.text+0x35), e= 1 [XOR EAX, EAX] 

0x401037 (.text+0x37), e= 1 [POP ESI] 

0x401038 (.text+0x38), e= 1 [RETN] EAX=0 


Nous pouvons utiliser grep ici. 


ARM 
sans optimisation Keil 6/2013 (Mode ARM) 
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main 
STMFD SP!, {R4,LR} 
MOV R4, #2 
B loc 368 
loc 35C ; CODE XREF: main+1C 
MOV RO, R4 
BL printing function 
ADD R4, R4, #1 
loc 368 ; CODE XREF: main+8 
CMP R4, #0xA 
BLT loc 35C 
MOV RO, #0 


LDMFD  SP!, {R4,PC} 


Le compteur de boucle i est stocké dans le registre R4. L'instruction MOV R4, #2 
initialise ;. Les instructions MOV RO, R4 et BL printing function composent le 
corps de la boucle, la premiére instruction préparant l'argument pour la fonction 
f() et la seconde l'appelant. L'instruction ADD R4, R4, #1 ajoute 1 à la variable à 
à chaque itération. CMP R4, #0xA compare i avec OXA (10). L'instruction suivante, 
BLT (Branch Less Than) saute si i est inférieur à 10. Autrement, O est écrit dans RO 
(puisque notre fonction renvoie 0) et l'exécution de la fonction se termine. 


avec optimisation Keil 6/2013 (Mode Thumb) 


main 
PUSH {R4,LR} 
MOVS R4, #2 
loc 132 ; CODE XREF: _main+E 
MOVS RO, R4 
BL printing function 
ADDS R4, R4, #1 
CMP R4, #0xA 
BLT loc 132 
MOVS RO, #0 
POP {R4,PC} 


Pratiquement la méme chose. 


avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


_main 
PUSH {R4,R7,LR} 
MOVW RA, #0x1124 ; "sdin" 
MOVS R1, #2 
MOVT .W R4, #0 
ADD R7, SP, #4 


ADD R4, PC 
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MOV RO, R4 
BLX | printf 
MOV RO, R4 
MOVS R1, £3 
BLX | printf 
MOV RO, R4 
MOVS R1, #4 
BLX | printf 
MOV RO, R4 
MOVS R1, #5 
BLX | printf 
MOV RO, R4 
MOVS R1, £6 
BLX | printf 
MOV RO, R4 
MOVS R1, #7 
BLX | printf 
MOV RO, R4 
MOVS R1, £8 
BLX | printf 
MOV RO, R4 
MOVS R1, #9 
BLX | printf 
MOVS RO, #0 
POP (RA, R7,PC] 


En fait, il y avait ceci dans ma fonction f() : 


void printing function(int i) 


1 
}; 


printf ("%d\n", i); 


Donc, non seulement LLVM déroule la boucle, mais aussi inline ma fonction trés 
simple et insére son corps 8 fois au lieu de l'appeler. 


Ceci est possible lorsque la fonction est trés simple (comme la mienne) et lorsqu'elle 
n'est pas trop appelée (comme ici). 


ARM64: GCC 4.9.1 avec optimisation 


Listing 1.173 : GCC 4.9.1 avec optimisation 


printing function: 

; préparer le second argument de printf(): 
mov wl, wO 

; charger l'adresse de la chaíne "f(%d)\n 
adrp x0, .LCO 


add x0, x0, :1012:.LC0 
; seulement sauter ici au lieu de sauter avec lien et retour: 
b printf 


main: 
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; sauver FP et LR dans la pile locale: 
stp x29, x30, [sp, -32]! 

; préparer une structure de pile: 
add x29, sp, 0 

; sauver le contenu du registre X19 dans la pile locale: 
str x19, [sp,16] 

; nous allons utiliser le registre W19 comme compteur. 

; lui assigner une valeur initiale de 2: 


mov w19, 2 
.L3: 
; préparer le premier argument de printing function(): 
mov w0, w19 
; incrémenter le registre compteur. 
add w19, w19, 1 
; ici WO contient toujours la valeur du compteur avant incrémentation. 
bl printing function 
; est-ce terminé? 
cmp w19, 10 
; non, sauter au début du corps de boucle: 
bne .L3 
; renvoyer 60 
mov w0, 0 


restaurer le contenu du registre X19: 
ldr x19, [sp,16] 

restaurer les valeurs de FP et LR: 
ldp x29, x30, [sp], 32 
ret 


.LC0: 
.string "f(%d)\n" 


ARM64: GCC 4.9.1 sans optimisation 


Listing 1.174 : GCC 4.9.1 -fno-inline sans optimisation 


.LC0: 
.string "f(%d)\n" 
printing function: 
; sauver FP et LR dans la pile locale: 


stp x29, x30, [sp, -32]! 
; préparer la pile locale: 
add x29, sp, 0 


; sauver le contenu du registre W0: 
str w0, [x29,28] 

; charger l'adresse de la chaîne "f(%d)\n" 
adrp x0, .LCO 
add x0, x0, :1012:.LC0 

; recharger la valeur entrée depuis le pile locale dans le registre WO: 
ldr wl, [x29,28] 

; appeler printf() 
bl printf 

; restaurer les valeurs de FP et LR: 
ldp x29, x30, [sp], 32 
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ret 
main: 
; sauvegarder FP et LR sur la pile locale: 
stp x29, x30, [sp, -32]! 
; préparer la structure de pile: 
add x29, sp, 0 
; initialiser le compteur 
mov w0, 2 


; le stocker dans l'espace alloué pour lui dans la pile locale: 
str w0, [x29,28] 
; passer le corps de la boucle et sauter aux instructions de vérification de 
la Con Enon de boucle: 


„L4: 
; charger la valeur du compteur dans WO. 
; ce sera le premier argument de printing function() 
ldr w0, [x29,28] 
; appeler printing function(): 
bl printing function 
; incrémenter la valeur du compteur: 
ldr w0, [x29,28] 
add w0, wỌ, 1 
str w0, [x29,28] 
.L3: 
; tester condition de boucle. 
; charger la valeur du compteur: 
ldr w0, [x29,28] 
est-ce 9? 
cmp w0, 9 
inférieur ou égal? alors sauter au début du corps de boucle: 
autrement, ne rien faire. 


ble .L4 

; renvoyer 60 
mov w0, 0 

; restaurer les valeurs de FP et LR: 
ldp x29, x30, [sp], 32 
ret 


MIPS 


Listing 1.175 : GCC 4.4.5 sans optimisation (IDA) 


main: 


; IDA ne connaít pas le nom des variables dans la pile locale 
; Nous pouvons leurs en donner un manuellement: 


i = -0x10 
saved FP = -8 
saved_RA = -4 


; prologue de la fonction: 
addiu  $sp, -0x28 
Sw $ra, 0x28+saved_RA($sp) 
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SW $fp, Ox28+saved FP($sp) 
move $fp, $sp 
; initialiser le compteur à 2 et stocker cette valeur dans la pile locale 


li $v0, 2 

SW $v0, 0x28+i($fp) 
; pseudo-instruction. "BEQ $ZERO, $ZERO, loc 9C" c'est en fait: 

b loc 9C 

or $at, $zero ; slot de délai de branchement, NOP 
loc 80: # CODE XREF: main+48 


; charger la valeur du compteur depuis la pile locale et appeler 
printing function(): 


lw $a0, 0x28+1($fp) 
jal printing function 
or $at, $zero ; slot de délai de branchement, NOP 
; charger le compteur, l'incrémenter, et le stocker de nouveau: 
lw $vO, 0x28+1($fp) 
or $at, $zero ; NOP 
addiu $v0, 1 
SW $v0, 0x28+i($fp) 
loc 9C: # CODE XREF: main+18 
; tester le compteur, est-ce 10? 
lw $v0, 0x28+1($fp) 
or $at, $zero ; NOP 


slti $v0, OxA 
; si il est inférieur à 10, sauter en loc 80 (début du corps de la boucle): 
bnez $vO, loc 80 


or $at, $zero ; slot de délai de branchement, NOP 
; fin, renvoyer 60: 
move $v0, $zero 


; épilogue de la fonction: 
move $sp, $fp 


lw $ra, 0x28+saved_RA($sp) 

lw $fp, Ox28+saved FP($sp) 

addiu $sp, 0x28 

jr $ra 

or $at, $zero ; slot de délai de branchement, NOP 


L'instruction qui est nouvelle pour nous est B. C'est la pseudo instruction (BEQ). 


Encore une chose 


Dans le code généré, nous pouvons voir: aprés avoir initialisé i, le corps de la boucle 
n'est pas exécuté, car la condition sur i est d'abord vérifiée, et c'est seulement aprés 
cela que le corps de la boucle peut étre exécuté. Et cela est correct. 


Ceci car si la condition de boucle n'est pas remplie au début, le corps de la boucle 
ne doit pas étre exécuté. Ceci est possible dans le cas suivant: 


for (i20; i«nombre total d element à traiter; i++) 
corps de la boucle; 
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Si nombre total d element à traiter est 0, le corps de la boucle ne sera pas exécuté 
du tout. 


C'est pourquoi la condition est testée avant l'exécution. 


Toutefois, un compilateur qui optimise pourrait échanger le corps de la boucle et la 
condition, si il est certain que la situation que nous venons de décrire n'est pas pos- 
sible (comme dans le cas de notre exemple simple, et en utilisant des compilateurs 
comme Keil, Xcode (LLVM) et MSVC avec le flag d'optimisation. 


1.22.2 Routine de copie de blocs de mémoire 


Les routines réelles de copie de mémoire copient 4 ou 8 octets à chaque itération, 
utilisent SIMD1%, la vectorisation, etc. Mais dans un but didactique, cet exemple est 
le plus simple possible. 


#include <stdio.h> 


void my memcpy (unsigned char* dst, unsigned char* src, size t cnt) 
{ 
size t i; 
for (i=0; i<cnt; i++) 
dst[il=src[i]; 
}; 


Implémentation simple 


Listing 1.176 : GCC 4.9 x64 optimisé pour la taille (-Os) 


my_memcpy: 

: RDI = adresse de destination 
: RSI = adresse source 

; RDX = taille de bloc 


; initialiser le compteur (i) à O 


xor eax, eax 
.L2: 
; tous les octets sont-ils copiés? alors sortir: 
cmp rax, rdx 
je .L5 
; charger l'octet en RSI+i: 
mov cl, BYTE PTR [rsi+rax] 
; stocker l'octet en RDI+i: 
mov BYTE PTR [rdi+rax], cl 
inc rax ; i++ 
jmp .L2 
¿5 
ret 


103Single Instruction, Multiple Data 
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Listing 1.177 : GCC 4.9 ARM64 optimisé pour la taille (-Os) 


my memcpy: 
; X0 = adresse de destination 
; X1 = adresse source 
; X2 = taille de bloc 


; initialiser le compteur (i) à 0 


mov x3, 0 

.L2: 

; tous les octets sont-ils copiés? alors sortir: 
cmp x3, x2 
beq .L5 


; charger l'octet en X1+i: 
ldrb w4, [x1,x3] 
; stocker l'octet en X0-«i: 
strb w4, [x0,x3] 


add x3, x3, 1 ; i++ 
b .L2 

.L5: 
ret 


Listing 1.178 : avec optimisation Keil 6/2013 (Mode Thumb) 


my memcpy PROC 


; RO = adresse de destination 
; R1 = adresse source 
; R2 = taille de bloc 
PUSH {r4, lr} 
; initialiser le compteur (i) à 0 
MOVS r3,*0 
; la condition est testée à la fin de la fonction, donc y sauter: 
B [L0.12| 
[L0.6| 
; charger l'octet en Rl+i: 
LDRB rA, [r1,r3] 
; stocker l'octet en RO+i: 
STRB rA, [r0,r3] 
; lt 
ADDS r3,r3,#1 
[L0.12| 
; i<taille? 
CMP r3,r2 
; sauter au début de la boucle si c'est le cas: 
BCC [L0.6| 
POP {r4,pc} 
ENDP 


ARM en mode ARM 


Keil en mode ARM tire pleinement avantage des suffixes conditionnels: 
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Listing 1.179 : avec optimisation Keil 6/2013 (Mode ARM) 


my memcpy PROC 

; RO = adresse de destination 
; R1 = adresse source 

; R2 = taille de bloc 


; initialiser le compteur (i) à 0 
MOV r3,*0 
|LO.4| 
; tous les octets sont-ils copiés? 
CMP r3,r2 
; le bloc suivant est exécuté seulement si la condition less than est 
remplie, 
; i.e., if R2«R3 ou i<taille. 
; charger l'octet en Rl+i: 
LDRBCC r12,[r1,r3] 
; stocker l'octet en RO+i: 
STRBCC r12,[r0, r3] 
; lt 
ADDCC r3,r3,#1 
; la dernière instruction du bloc conditionnel. 
; sauter au début de la boucle si i<taille 
; ne rien faire autrement (i.e., si i»-taille) 


BCC |L0.4] 
; retourner 

BX lr 

ENDP 


C'est pourquoi il y a seulement une instruction de branchement au lieu de 2. 


MIPS 

Listing 1.180 : GCC 4.4.5 optimisé pour la taille (-Os) (IDA) 
my memcpy: 
; sauter à la partie test de la boucle: 


b loc 14 
; initialiser le compteur (i) à 0 
; il se trouvera toujours dans $v0: 
move $v0, $zero ; slot de délai de branchement 


loc 8: # CODE XREF: my memcpy-1C 
; charger l'octet non-signé à l'adresse $t0 dans $vl: 
lbu $v1, 0($t0) 
; incrémenter le compteur (i): 
addiu $v0, 1 
; stocker l'octet en $a3 
sb $v1, 0($a3) 


loc 14: # CODE XREF: my memcpy 
; tester si le compteur (i) dans $v0 est toujours inférieur au 3ème argument 


de la fonction ("cnt" dans $a2): 
sltu $v1, $vO, $a2 
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former l'adresse de l'octet dans le bloc source: 
addu $t0, $al, $v0 
; $t0 = $al+$v0 = srcti 
; sauter au corps de la boucle si le compteur est toujours inférieur à "cnt": 
bnez $v1, loc 8 
former l'adresse de l'octet dans le bloc de destination ($a3 = $a0+$v0 = 
dst+i): 


addu $a3, $a0, $v0 ; slot de délai de branchement 
terminer si BNEZ n'a pas exécuté de saut: 

jr $ra 

or $at, $zero ; slot de délai de branchement, NOP 


Nous avons ici deux nouvelles instructions: LBU («Load Byte Unsigned » charger un 
octet non signé) et SB («Store Byte » stocker un octet). 


Tout comme en ARM, tous les registres MIPS ont une taille de 32-bit, il n'y en a pas 
d'un octet de large comme en x86. 


Donc, lorsque l'on travaille avec des octets seuls, nous devons utiliser un registre 
de 32-bit pour chacun d'entre eux. 


LBU charge un octet et met les autres bits à zéro («Unsigned »). 


En revanche, l'instruction LB («Load Byte ») étend le signe de l'octet chargé sur 32- 
bit. 


SB écrit simplement un octet depuis les 8 bits de poids faible d'un registre dans la 
mémoire. 


Vectorisation 


GCC avec optimisation peut faire beaucoup mieux avec cet exemple: 1.36.1 on 
page 534. 


1.22.3 Vérification de condition 


Il est important de garder à l'esprit que dans une boucle for(), la condition est vérifiée 
préalablement à l'itération du corps de la boucle et non pas aprés. Cela étant il est 
Souvent plus pratique pour le compilateur de placer les instructions qui effectuent 
le test après le corps de la boucle. Il arrive aussi qu'il rajoute des vérifications au 
début du corps de la boucle. 


Par exemple: 


#include <stdio.h> 


void f(int start, int finish) 
{ 
for (; start<finish; start++) 
printf ("%d\n", start); 
}; 


GCC 5.4.0 x64 en mode optimisé: 
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f: 

; check condition (1): 
cmp edi, esi 
jge .L9 
push rbp 
push rbx 
mov ebp, esi 
mov ebx, edi 
sub rsp, 8 

L5; 
mov edx, ebx 
xor eax, eax 
mov esi, OFFSET FLAT:.LCO ; "%d\n" 
mov edi, 1 
add ebx, 1 
call . printf chk 

; check condition (2): 
cmp ebp, ebx 
jne .L5 
add rsp, 8 
pop rbx 
pop rbp 

.L9: 
rep ret 


Nous constatons la présence de deux vérifications. 


Le code décompilé produit par Hex-Rays (dans sa version 2.2.0) est celui-ci: 


void cdecl f(unsigned int start, unsigned int finish) 


{ 
unsigned int v2; // ebx@2 
. int64 v3; // rdx@3 


if ( (signed int)start « (signed int)finish ) 


1 
v2 = start; 
do 
1 
v3 = V2++; 
_printf_chk(1LL, "%d\n", v3); 
while ( finish != v2 ); 
} 
} 


Dans le cas présent, il ne fait aucun doute que la structure do/while() peut étre 
remplacée par une construction for(), et que le premier contróle peut étre supprimé. 


1.22.4 Conclusion 


Squelette grossier d’une boucle de 2 a 9 inclus: 
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Listing 1.181 : x86 


mov [counter], 2 ; initialisation 
jmp check 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser la variable compteur dans la pile locale 
add [counter], 1 ; incrémenter 
check: 
cmp [counter], 9 
jte body 


L'opération d'incrémentation peut étre représentée par 3 instructions dans du code 
non optimisé: 


Listing 1.182 : x86 


MOV [counter], 2 ; initialisation 
JMP check 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser la variable compteur dans la pile locale 
MOV REG, [counter] ; incrémenter 
INC REG 
MOV [counter], REG 
check: 
CMP [counter], 9 
JLE body 


Si le corps de la boucle est court, un registre entier peut étre dédié à la variable 
compteur: 


Listing 1.183 : x86 


MOV EBX, 2 ; initialisation 
JMP check 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser le compteur dans EBX, mais ne pas le modifier! 
INC EBX ; incrémenter 
check: 
CMP EBX, 9 
JLE body 


Certaines parties de la boucle peuvent étre générées dans un ordre différent par le 
compilateur: 


Listing 1.184 : x86 


MOV [counter], 2 ; initialisation 
JMP label check 
label increment: 
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ADD [counter], 1 ; incrémenter 
label check: 
CMP [counter], 10 
JGE exit 
; corps de la boucle 
; faire quelque cose ici 
; utiliser la variable compteur dans la pile locale 
JMP label increment 
exit: 


En général, la condition est testée avant le corps de la boucle, mais le compilateur 
peut la réarranger afin que la condition soit testée aprés le corps de la boucle. 


Cela est fait lorsque le compilateur est certain que la condition est toujours vraie à 
la premiére itération, donc que le corps de la boucle doit étre exécuté au moins une 
fois: 


Listing 1.185 : x86 


MOV REG, 2 ; initialisation 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser le compteur dans REG, mais ne pas le modifier! 
INC REG ; incrémenter 
CMP REG, 10 
JL body 


En utilisant l'instruction LOOP. Ceci est rare, les compilateurs ne l'utilisent pas. Lorsque 
vous la voyez, c'est le signe que le morceau de code a été écrit à la main: 


Listing 1.186 : x86 


; compter de 10 à 1 
MOV ECX, 10 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser le compteur dans ECX, mais ne pas le modifier! 
LOOP body 


ARM 


Le registre R4 est dédié à la variable compteur dans cet exemple: 


Listing 1.187 : ARM 


MOV R4, 2 ; initialisation 
B check 
body: 
; corps de la boucle 
; faire quelque chose ici 
; utiliser le compteur dans R4, mais ne pas le modifier! 
ADD R4,R4, 41 ; incrémenter 
check: 
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CMP R4, £10 
BLT body 


1.22.5 Exercices 
* http://challenges.re/54 
* http://challenges.re/55 
* http://challenges.re/56 
* http://challenges.re/57 


1.23 Plus d'information sur les chaines 


1.23.1 strlen() 


Parlons encore une fois des boucles. Souvent, la fonction strlen() 104 est implé- 
mentée en utilisant une déclaration while(). Voici comment cela est fait dans les 


bibliothéques standards de MSVC: 


int my strlen (const char * str) 

1 
const char *eos = str; 
while( *eos++ ) ; 


return( eos - str - 1 ); 


} 
int main() 
{ 
// test 
return my_strlen("hello!"); 
}; 
x86 


MSVC sans optimisation 


Compilons: 


| eos$ -4 ; Size 
_str$ 8 ; size 
_strlen PROC 

push ebp 

mov ebp, esp 

push ecx 


104 compter les caractères d'une chaîne en langage C 
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mov eax, DWORD PTR str$[ebp] ; copier le pointeur sur la chaîne 
LL st LL 
mov DWORD PTR _eos$[ebp], eax ; le copier dans la variable locale 
LL S LL 

$LN2Gstrlen : 
mov ecx, DWORD PTR eos$[ebp] ; ECX=eos 


; prendre un octet 8-bit depuis l'adresse dans ECX et le copier 
; comme une valeur 32-bit dans EDX avec extension du signe 


movsx edx, BYTE PTR [ecx] 
mov eax, DWORD PTR eos$[ebp] ; EAX-eos 
add eax, 1 ; incrémenter EAX 


mov DWORD PTR eos$[ebp], eax ; remettre EAX dans "eos" 

test edx, edx ; est-ce que EDX est a zéro? 

je SHORT $LNlestrlen_ ; oui, alors finir la boucle 

jmp SHORT $LN2@strlen_ ; continuer la boucle 
$LN1@strlen_: 


; ici nous calculons la différence entre deux pointeurs 


mov eax, DWORD PTR _eos$[ebp] 
sub eax, DWORD PTR _str$[ebp] 


sub eax, 1 ; soustraire 1 du résultat et sortir 
mov esp, ebp 

pop ebp 

ret 0 


_strlen_ ENDP 


Nous avons ici deux nouvelles instructions: MOVSX et TEST. 


La premiére—MOVSX—prend un octet depuis une adresse en mémoire et stocke la 
valeur dans un registre 32-bit. MOVSX signifie MOV with Sign-Extend (déplacement 
avec extension de signe). MOVSX met le reste des bits, du 8ème au 31ème, à 1 si 
l'octet source est négatif ou à 0 si il est positif. 


Et voici pourquoi. 


Par défaut, le type char est signé dans MSVC et GCC. Si nous avons deux valeurs 
dont l'une d'elle est un char et l'autre un int, (int est signé aussi), et si la première 
valeur contient -2 (codé en OxFE) et que nous copions simplement cet octet dans le 
conteneur int, cela fait 0x000000FE, et ceci, pour le type int représente 254, mais pas 
-2. Dans un entier signé, -2 est codé en OxFFFFFFFE. Donc, si nous devons transférer 
OxFE depuis une variable de type char vers une de type int, nous devons identifier 
son signe et l'étendre. C'est ce qu'effectue MOVSX. 


Il est difficile de dire si le compilateur doit stocker une variable char dans EDX, il pour- 
rait simplement utiliser une partie 8-bit du registre (par exemple DL). Apparemment, 
l'allocateur de registre fonctionne comme ca. 


Ensuite nous voyons TEST EDX, EDX. Vous pouvez en lire plus à propos de l'instruc- 
tion TEST dans la section concernant les champs de bit (1.28 on page 392). Ici cette 
instruction teste simplement si la valeur dans EDX est égale à 0. 
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GCC sans optimisation 


Essayons GCC 4.4.1: 


public strlen 


strlen proc near 
eos = dword ptr -4 
arg_0 = dword ptr 8 
push ebp 
mov ebp, esp 
sub esp, 10h 
mov eax, [ebp+arg 0] 
mov [ebp+eos], eax 


loc 80483F0: 
mov eax, [ebp+eos] 
movzx eax, byte ptr [eax] 
test al, al 


setnz al 
add [ebp+eos], 1 
test al, al 
jnz short loc 80483F0 
mov edx, [ebp+eos] 
mov eax, [ebp+arg 0] 
mov ecx, edx 
sub ecx, eax 
mov eax, ecx 
sub eax, 1 
leave 
retn 

strlen endp 


Le résultat est presque le méme qu’avec MSVC, mais ici nous voyons MOVZX au lieu 
de MOVSX. MOVZX signifie MOV with Zero-Extend (déplacement avec extension a 0). 
Cette instruction copie une valeur 8-bit ou 16-bit dans un registre 32-bit et met les 
bits restant a 0. En fait, cette instructions n'est pratique que pour nous permettre 
de remplacer cette paire d’instructions: 

xor eax, eax / mov al, [...]. 


D'un autre cóté, il est évident que le compilateur pourrait produire ce code: 

mov al, byte ptr [eax] / test al, al—c'est presque le méme, toutefois, les 
bits les plus haut du registre EAX vont contenir des valeurs aléatoires. Mais, admet- 
tons que c'est un inconvénient du compilateur—-il ne peut pas produire du code 
plus compréhensible. À strictement parler, le compilateur n'est pas du tout obligé 
de générer du code compréhensible par les humains. 


La nouvelle instruction suivante est SETNZ. Ici, si AL ne contient pas zéro, test al, 
al met le flag ZF à 0, mais SETNZ, si ZF==0 (NZ signifie not zero, non zéro) met AL 
à 1. En langage naturel, si AL n'est pas zéro, sauter en loc 80483F0. Le compilateur 
génére du code redondant, mais n'oublions pas qu'il n'est pas en mode optimisation. 
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MSVC avec optimisation 


Maintenant, compilons tout cela avec MSVC 2012, avec le flag d'optimisation (/0x) : 


Listing 1.188 : MSVC 2012 avec optimisation/ObO 


_str$ = 8 ; size = 4 
_strlen PROC 
mov edx, DWORD PTR str$[esp-4] ; EDX -> pointeur sur la chaine 
mov eax, edx ; déplacer dans EAX 
$LL2@strlen: 
mov cl, BYTE PTR [eax] ; CL = *EAX 
inc eax ; EAX++ 
test cl, cl ; CL==0? 
jne SHORT $LL2@strlen ; non, continuer la boucle 
sub eax, edx ; calculer la différence entre 
les pointeurs 
dec eax ; décrémenter EAX 
ret 0 


_strlen ENDP 


C'est plus simple maintenant. Inutile de préciser que le compilateur ne peut utiliser 
les registres aussi efficacement que dans une petite fonction, avec peu de variables 
locales. 


INC/DEC—sont des instructions de incrémentation/décrémentation, en d'autres mots: 
ajouter ou soustraire 1 d'une/à une variable. 
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MSVC avec optimisation + OllyDbg 


Nous pouvons essayer cet exemple (optimisé) dans OllyDbg. Voici la première itéra- 
tion: 


main thread, module ex1 


0 D 
MOU EAX, El 


Ñ 


1.01381006 


ØLFFFFFFFF) 
OLFFFFEFFF) 
BL FFFFFFFF) 
OLFFFFFFFF) 
7EFDDGGG( FFF) 
GCFFFFFFFF) 


DANDO M mm 


a 


LastErr 90008086 ERRO 
o 46 (NO,NB,E,BE,N 


[61383006]=68 ('h') 

CL-ES 

Jump from 138188B 

Loop 81381886: loop variable EAX(+1) 


RETURN from ex1.0 a 
ASCII "hellot” 
RETURN from ex1.@ 


Pointer to next Sly 


Fig. 1.58: OllyDbg : début de la première itération 


Nous voyons qu'OllyDbg a trouvé une boucle et, par facilité, a mis ses instructions 
entre crochets. En cliquant sur le bouton droit sur EAX, nous pouvons choisir «Follow 
in Dump » et la fenétre de la mémoire se déplace jusqu'à la bonne adresse. Ici, nous 
voyons la chaíne «hello! » en mémoire. Il y a au moins un zéro aprés cette derniére 
et ensuite des données aléatoires. 


Si OllyDbg voit un registre contenant une adresse valide, qui pointe sur une chaine, 
il montre cette chaîne. 
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Appuyons quelques fois sur F8 (enjamber), pour aller jusqu'au début du corps de la 


boucle: 


CPU - main thread, module ex1 


31000 $ 8B5424 84 


Loop 81981806: 


0000000 Nm) 


coco 
© © © © © © © © © TN 
; 2G 


MOV EDX, DWORD PTR SS: [ARG. 1] 
MOU EAX, EDX 
MOU CL.BVTE PTR DS:CEAXI 


CL, CL 
JNZ_SHORT 61381006 
SUB EAX, EDX 
DEC EAX 
RETN 
INTS 
IN 
IN 


B 
loop variable EAX(+1) 


gogogaga 1 
96000088 


' 01381006 ex1.01381006 


ES g t B(FFFFFFFF) 

cs : B(FFFFFFFF) 

SS 8 OLFFFFFFFE) 
OLFFFFFFFE) 
?EFDDOGO(FFF) 
BCFFFFFFFF) 


bastis 00000000 ERROR, SUCCESS: 


DO3BF 
DO3BFF38 
BO3BFFSC 
aaah 
aaa 
SBFF3 
96968630 


Pointer to next Sly 


Fig. 1.59: OllyDbg : début de la seconde itération 


Nous voyons qu'EAX contient l'adresse du second caractére de la chaine. 
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Nous devons appuyons un certain nombre de fois sur F8 afin de sortir de la boucle: 


CPU - main thread, module ex1  - [n x! 
^ 


$ 985424 84 MOV EDX, DWORD PTR SS: [ARG. 1] 
. MOV EAX, EDX 
MOU CL,BYTE PTR DS:[EAX] 

IC ERX 


L,CL 


JNZ SHORT 61331006 


SUB , 
DEC ERX 
TRIS 

IN ' 61381980 


n E: FFFFFFFF) 

IN FFFFFFFF) 

FFFFFFFF) 

OLFFFFFFFF) 
7EFDDGG0( FFF) 

: GCFFFFFFFF) 


ERROR_SUCCESS 


ooo 


al 


E,BE,NS,PE,GE,LE) 


U rom 
II "hello 
RETURN from ex1.8 


Fig. 1.60: OllyDbg : calcul de la différence entre les pointeurs 


Nous voyons qu'EAX contient l'adresse de l'octet à zéro situé juste aprés la chaîne. 
Entre temps, EDX n'a pas changé, donc il pointe sur le début de la chaîne. 


La différence entre ces deux valeurs est maintenant calculée. 
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L'instruction SUB vient juste d'étre effectuée: 


CPU - main thread, module ex1 


$ 3B5424 84 MOV EDX, DWORD PTR SS: LARG. 1] 
MOU EAX, EDX 

MOV CL, BYTE PTR DS:LERX1 
INC_EAX 


"hellot" 


) DAA 


Bt FFFFFFFF) 
Bt FFFFFFFF) 
at FFFFFFFF) 
Bt FFFFFFFF) 
rEFDDaaatFFF) 
OCFFFFFFFF) 


DOS: 


EFL 
nna 


——— - o 986| ASCII hellot” - 
EEE? : ; l um /$80| RETURN from ex1.0 


; [Pointer to next 


Fig. 1.61: OllyDbg : maintenant décrémenter EAX 


La différence entre les deux pointeurs est maintenant dans le registre EAX—7. Effec- 
tivement, la longueur de la chaine «hello! » est 6, mais avec l'octet à zéro inclus—7. 
Mais strlen() doit renvoyer le nombre de caractère non-zéro dans la chaîne. Donc 
la décrémentation est effectuée et ensuite la fonction sort. 


GCC avec optimisation 


Regardons ce que génére GCC 4.4.1 avec l'option d'optimisation -03 : 


public strlen 


strlen proc near 
arg 0 - dword ptr 8 
push ebp 
mov ebp, esp 
mov ecx, [ebp+arg 0] 
mov eax, ecx 


loc 8048418: 
movzx edx, byte ptr [eax] 
add eax, 1 
test dl, dl 
jnz short loc 8048418 
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not ecx 
add eax, ecx 
pop ebp 
retn 
strlen endp 


mov dl, byte ptr [eax]. Ici GCC génére presque le méme code que MSVC, à l'ex- 
ception de la présence de MOVZX. Toutefois, ici, MOVZX pourrait étre remplacé par 
mov dl, byte ptr [eax]. 


Peut-étre est-il plus simple pour le générateur de code de GCC se se rappeler que 
le registre 32-bit EDX est alloué entiérement pour une variable char et il est sür que 
les bits en partie haute ne contiennent pas de bruit indéfini. 


Aprés cela, nous voyons une nouvelle instruction—NOT. Cette instruction inverse tout 
les bits de l'opérande. 

Elle peut étre vu comme un synonyme de l'instruction XOR ECX, Offffffffh. NOT 
et l'instruction suivante ADD calcule la différence entre les pointeurs et soustrait 1, 
d'une facon différente. Au début, ECX, oü le pointeur sur str est stocké, est inversé 
et 1 en est soustrait. 


En d'autres mots, à la fin de la fonction juste aprés le corps de la boucle, ces opéra- 
tions sont exécutées: 


ecx=str; 
eax-eos; 
ecx=(-ecx)-1; 
eax=eax+ecx 
return eax 


... et ceci est effectivement équivalent à: 


ecx=str; 
eax-eos; 
eax=eax-ecx; 
eax=eax-1; 
return eax 


Pourquoi est-ce que GCC décide que cela est mieux? Difficile à deviner. Mais peut- 
étre que les deux variantes sont également efficaces. 


ARM 
ARM 32-bit 


sans optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Listing 1.189 : sans optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


_strlen 
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eos = 
str = -4 


SUB SP, SP, #8 ; allouer 8 octets pour les variables locales 
STR RO, [SP,#8+str] 
LDR RO, [SP,#8+str] 
STR RO, [SP,#8+eos] 


loc 2CB8 ; CODE XREF: _strlen+28 
LDR RO, [SP,*8+eos] 
ADD R1, RO, #1 
STR R1, [SP,+8+eos] 
LDRSB RO, [RO] 
CMP RO, #0 
BEQ loc 2CD4 
B loc 2CB8 

loc 2CD4 ; CODE XREF: strlen+24 
LDR RO, [SP,+t8+eos] 
LDR R1, [SP,#8+str] 
SUB RO, RO, R1 ; RO=e0s-str 
SUB RO, RO, +1 ; RO-RO-1 
ADD SP, SP, £8 ; libérer les 8 octets alloués 


LLVM sans optimisation génére beaucoup trop de code, toutefois, ici nous pouvons 
voir comment la fonction travaille avec les variables locales. Il y a seulement deux 
variables locales dans notre fonction: eos et str. Dans ce listing, généré par IDA, nous 
avons renommé manuellement var 8 et var 4 en eos et str. 


La premiére instruction sauve simplement les valeurs d'entrée dans str et eos. 
Le corps de la boucle démarre au label loc 2CB8. 


Les trois premiére instructions du corps de la boucle (LDR, ADD, STR) chargent la 
valeur de eos dans RO. Puis la valeur est incrémentée et sauvée dans eos, qui se 
trouve sur la pile. 


L'instruction suivante, LDRSB RO, [R0] («Load Register Signed Byte»), charge un 
octet depuis la mémoire à l'adresse stockée dans RRO et étend le signe à 32-bit!%. 
Ceci est similaire à l'instruction MOVSX en x86. 


Le compilateur traite cet octet comme signé, puisque le type char est signé selon la 
norme C. Il a déjà été écrit à propos de cela (1.23.1 on page 264) dans cette section, 
en relation avec le x86. 


Il est à noter qu'il est impossible en ARM d'utiliser séparément la partie 8- ou 16-bit 
d'un registre 32-bit complet, comme c'est le cas en x86. 


Apparemment, c'est parce que le x86 à une énorme histoire de rétro-compatibilité 
avec ses ancétres, jusqu'au 8086 16-bit et méme 8080 8-bit, mais ARM a été déve- 
loppé à partir de zéro comme un processeur RISC 32-bit. 


105| e compilateur Keil considére le type char comme signé, tout comme MSVC et GCC. 
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Par conséquent, pour manipuler des octets séparés en ARM, on doit tout de méme 
utiliser des registres 32-bit. 


Donc, LDRSB charge des octets depuis la chaine vers RO, un par un. Les instructions 
suivantes, CMP et BEQ vérifient si l'octet chargé est 0. Si il n'est pas à O, le contrôle 
passe au début du corps de la boucle. Et si c'est 0, la boucle est terminée. 


À la fin de la fonction, la différence entre eos et str est calculée, 1 en est soustrait, 
et la valeur résultante est renvoyée via RO. 


N.B. Les registres n'ont pas été sauvés dans cette fonction. 


C'est parce que dans la convention d'appel ARM, les registres RO-R3 sont des «re- 
gistres scratch », destinés à passer les arguments, et il n'est pas requis de restaurer 
leur valeur en sortant de la fonction, puisque la fonction appelante ne va plus les 
utiliser. Par conséquent, ils peuvent étre utilisés comme bien nous semble. 


Il n'y a pas d'autres registres utilisés ici, c'est pourquoi nous n'avons rien à sauve- 
garder sur la pile. 


Ainsi, le contróle peut étre rendu à la fonction appelante par un simple saut (BX), à 
l'adresse contenue dans le registre LR. 


avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


Listing 1.190 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


_strlen 
MOV R1, RO 
loc_2DF6 
LDRB.W R2, [R1],+1 
CMP R2, #0 
BNE loc 2DF6 
MVNS RO, RO 
ADD RO, R1 
BX LR 


Comme le conclut LLVM avec l'optimisation, eos et str n'ont pas besoin d'espace 
dans la pile, et peuvent toujours étre stockés dans les registres. 


Avant le début du corps de la boucle, str est toujours dans RO, et eos—dans R1. 


L'instruction LDRB.W R2, [R1],#1 charge, dans R2, un octet de la mémoire à l'adresse 
stockée dans R1, en étendant le signe à une valeur 32-bit, mais pas seulement cela. 
#1 à la fin de l'instruction indique un «Adressage post-indexé » («Post-indexed ad- 
dressing »), qui signifie que 1 doit être ajouté à R1 après avoir chargé l'octet. Pour 
en lire plus à ce propos: 1.39.2 on page 568. 


Ensuite vous pouvez voir CMP et BNE*% dans le corps de la boucle, ces instructions 
continuent de boucler jusqu'à ce que O soit trouvé dans la chaine. 


106 (PowerPC, ARM) Branch if Not Equal 
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Les instructions MVNS!?/ (inverse tous les bits, comme NOT en x86) et ADD calculent 
eos-str-1. (1.23.1 on page 271). En fait, ces deux instructions calculent RO = str+eos, 
qui est effectivement équivalent à ce qui est dans le code source, et la raison de ceci 
à déjà été expliquée ici (1.23.1 on page 271). 
Apparemment, LLVM, tout comme GCC, conclu que ce code peut étre plus court (ou 
plus rapide). 


avec optimisation Keil 6/2013 (Mode ARM) 


Listing 1.191 : avec optimisation Keil 6/2013 (Mode ARM) 


_strlen 
MOV R1, RO 


loc_2C8 
LDRB R2, [R1],#1 
CMP R2, #0 
SUBEQ RO, R1, RO 
SUBEQ RO, RO, +1 
BNE loc_2C8 
BX LR 


Presque la méme chose que ce que nous avions vu avant, à l'exception que l'expres- 
sion str - eos - 1 peut être calculée non pas à la fin de la fonction, mais dans le corps 
de la boucle. Le suffixe -EQ, comme nous devrions nous en souvenir, implique que 
l'instruction ne s'exécute que si les opérandes de la derniére instruction CMP qui a 
été exécutée avant étaient égaux. Ainsi, si RO contient O, les deux instructions SUBEQ 
sont exécutées et le résultat est laissé dans le registre RO. 


ARM64 


GCC avec optimisation (Linaro) 4.9 


my strlen: 
mov x1, x0 
; X1 est maintenant un pointeur temporaire (eos), se comportant comme 
m curseur 


; charger un octet de X1 dans W2, incrémenter X1 (post-index) 
ldrb w2, [x1],1 

; Compare and Branch if NonZero: comparer W2 avec 0, 

; sauter en .L58 si il ne l'est pas 

cbnz w2, .L58 

; calculer la différence entre le pointeur initial dans X0 

; et l'adresse courante dans X1 

sub x0, x1, x0 


107MoVe Not 
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; decrement lowest 32-bit of result 
sub wO, w0, #1 
ret 


L'algorithme est le méme que dans 1.23.1 on page 266 : trouver un octet a zéro, 
calculer la différence antre les pointeurs et décrémenter le résultat de 1.size t 
Quelques commentaires ont été ajouté par l'auteur de ce livre. 


La seule différence notable est que cet exemple est un peu faux: 
my strlen() renvoie une valeur int 32-bit, tandis qu'elle devrait renvoyer un type 
size t ou un autre type 64-bit. 


La raison est que, théoriquement, strlen() peut-étre appelée pour un énorme bloc 
de mémoire qui dépasse 4GB, donc elle doit étre capable de renvoyer une valeur 
64-bit sur une plate-forme 64-bit. 


À cause de cette erreur, la derniére instruction SUB opére sur la partie 32-bit du re- 
gistre, tandis que la pénultième instruction SUB travaille sur un registre 64-bit com- 
plet (elle calcule la différence entre les pointeurs). 


C'est une erreur de l'auteur, il est mieux de la laisser ainsi, comme un exemple de 
ce à quoi ressemble le code dans un tel cas. 


GCC sans optimisation (Linaro) 4.9 


my strlen: 
; prologue de la fonction 
sub sp, sp, £32 


; le premier argument (str) va étre stocké dans [sp,8] 
str x0, [sp,8] 
ldr x0, [sp,8] 

; copier "str" dans la variable "eos" 


str x0, [sp,24] 
nop 
.L62: 
; eost 
ldr x0, [sp,24] ; charger "eos" dans X0 
add x1, x0, 1 ; incrémenter X0 
str X1, [sp,24] ; sauver X0 dans "eos" 


; charger dans WO un octet de la mémoire à l'adresse dans X0 
ldrb w0, [x0] 
; est-ce zéro? (WZR est le registre 32-bit qui contient toujours zéro) 


cmp w0, wzr 
; sauter si différent de zéro (Branch Not Equal) 
bne .L62 


; octet à zéro trouvé. calculer maintenant la différence 
; charger "eos" dans X1 
ldr xl, [sp,24] 
; charger "str" dans X0 
ldr x0, [sp,8] 
; calculer la différence 
sub x0, x1, x0 
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; décrémenter le résultat 


sub wO, w0, #1 

; épilogue de la fonction 
add sp, sp, 32 
ret 


C’est plus verbeux. Les variables sont beaucoup manipulées vers et depuis la mé- 
moire (pile locale). Il y a la méme erreur ici: l'opération de décrémentation se produit 
sur la partie 32-bit du registre. 


MIPS 
Listing 1.192 : avec optimisation GCC 4.4.5 (IDA) 
my strlen: 
; la variable "eos" sera toujours dans $vl: 
move $v1, $a0 
loc 4: 
; charger l'octet à l'adresse dans "eos" dans $al: 
lb $al, 0($v1) 
or $at, $zero ; slot de délai de branchement, NOP 


; si l'octet chargé n'est pas zéro, sauter en loc 4: 

bnez $al, loc 4 
incrémenter "eos" de toutes facons: 

addiu $v1, 1 ; slot de délai de branchement 
boucle terminée. inverser variable "str": 

nor $vO, $zero, $a0 


; $vO=-str-1 
jr $ra 

valeur de retour = $v1 + $v0 = eos + ( -str-1 ) = eos - str - 1 
addu $v0, $v1, $v0 ; slot de délai de branchement 


Il manque en MIPS une instruction NOT, mais il y a NOR qui correspond à l'opération 
OR + NOT. 


Cette opération est largement utilisée en électronique digitale*%*?. Par exemple, l'Apol- 
lo Guidance Computer (ordinateur de guidage Apollo) utilisé dans le programme 
Apollo, a été construit en utilisant seulement 5600 portes NOR: [Jens Eickhoff, On- 
board Computers, Onboard Software and Satellite Operations: An Introduction, (2011)]. 
Mais l'élément NOT n'est pas trés populaire en programmation informatique. 


Donc, l'opération NOT est implémentée ici avec NOR DST, $ZERO, SRC. 


D'aprés le chapitre sur les fondamentaux nous savons qu'une inversion des bits d'un 
nombre signé est la méme chose que changer son signe et soustraire 1 du résultat. 


Donc ce que NOT fait ici est de prendre la valeur de str et de la transformer en -str - 1. 
L'opération d'addition qui suit prépare le résultat. 


108NOR est appelé «porte universelle » 
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1.23.2 Limites de chaines 


Il est intéressant de noter comment les paramètres sont passés à la fonction win32 
GetOpenFileName(). Afin de l'appeler, il faut définir une liste des extensions de fi- 
chier autorisées: 


OPENFILENAME *LPOPENFILENAME; 


char * filter = "Text files (*.txt)\O*.txt\OMS Word files (*.doc) ? 
Y N0*.docN0NO"; 


LPOPENFILENAME = (OPENFILENAME *)malloc(sizeof(OPENFILENAME)); 
LPOPENFILENAME->1pstrFilter = filter; 


if(GetOpenFileName(LPOPENFILENAME)) 
1 


Ce qui se passe ici, c'est que la liste de chaines est passée à GetOpenFileName(). 
Ce n'est pas un probléme de l'analyser: à chaque fois que l'on rencontre un octet 
nul, c'est un élément. Quand on rencontre deux octets nul, c'est la fin de la liste. Si 
vous passez cette chaíne à printf(), elle traitera le premier élément comme une 
simple chaine. 


Donc, ceci est un chaîne, ou...? Il est plus juste de dire que c'est un buffer contenants 
plusieurs chaínes-C terminées par zéro, qui peut étre stocké et traité comme un tout. 


Un autre exemple est la fonction strtok(). Elle prend une chaine et y écrit des octets 
nul. C'est ainsi qu'elle transforme la chaine d'entrée en une sorte de buffer, qui 
contient plusieurs chaínes-C terminées par zéro. 


1.24 Remplacement de certaines instructions arith- 
métiques par d'autres 
Lors de la recherche d'optimisation, une instruction peut-étre remplacée par une 


autre, ou méme par un groupe d'instructions. Par exemple, ADD et SUB peuvent se 
remplacer: ligne 18 de listado.3.122. 


Par exemple, l'instruction LEA est souvent utilisée pour des calculs arithmétiques 
simples: .1.6 on page 1333. 

1.24.1 Multiplication 

Multiplication en utilisant l'addition 


Voici un exemple simple: 


unsigned int f(unsigned int a) 


{ 
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return a*8; 


}; 


La multiplication par 8 a été remplacée par 3 instructions d'addition, qui font la 
même chose. Il semble que l'optimiseur de MSVC a décidé que ce code peut être 
plus rapide. 


Listing 1.193 : MSVC 2010 avec optimisation 


TEXT | SEGMENT 


_a$ = 8 ; size = 4 
AT PROC 
mov eax, DWORD PTR  a$[esp-4] 
add eax, eax 
add eax, eax 
add eax, eax 
ret 0 
f ENDP 
_TEXT ENDS 
END 


Multiplication en utilisant le décalage 


Les instructions de multiplication et de division par un nombre qui est une puissance 
de 2 sont souvent remplacées par des instructions de décalage. 


unsigned int f(unsigned int a) 


{ 
return a*4; 
}; 
Listing 1.194 : MSVC 2010 sans optimisation 
_a$ = 8 ; size = 4 
_f PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR a$[ebp] 
shl eax, 2 
pop ebp 
ret 0 
f ENDP 


La multiplication par 4 consiste en un décalage du nombre de 2 bits vers la gauche 
et l'insertion de deux bits a zéro sur la droite (les deux derniers bits). C'est comme 
multiplier 3 par 100 —nous devons juste ajouter deux zéros sur la droite. 


C'est ainsi que fonctionne l'instruction de décalage vers la gauche: 
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ARE ERE am d 
Les bits ajoutés à droite sont toujours des zéros. 


Multiplication par 4 en ARM: 
Listing 1.195 : sans optimisation Keil 6/2013 (Mode ARM) 


f PROC 
LSL r0,r0,#2 
BX lr 
ENDP 


Multiplication par 4 en MIPS: 
Listing 1.196 : GCC 4.4.5 avec optimisation (IDA) 


jr $ra 
sll $v0, $a0, 2 ; branch delay slot 


SLL signifie «Shift Left Logical » (décalage logique à gauche). 


Multiplication en utilisant le décalage, la soustraction, et l'addition 


Il est aussi possible de se passer des opérations de multiplication lorsque l'on multi- 
plie par des nombres comme 7 ou 17, toujours en utilisant le décalage. Les mathé- 
matiques utilisées ici sont assez faciles. 


32-bit 


#include <stdint.h> 


int fl(int a) 


1 

return a*7; 
}; 
int f2(int a) 
1 

return a*28; 
Ji 


int f3(int a) 
{ 


}; 


return a*17; 
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x86 
Listing 1.197 : MSVC 2012 avec optimisation 
; a*7 
_a$ = 8 
_f1 PROC 
mov ecx, DWORD PTR a$[esp-4] 
; ECX=a 
lea eax, DWORD PTR [ecx*8] 
; EAX=ECX*8 
sub eax, ecx 
; EAX=EAX-ECX=ECX*8 - ECX=ECX*7=a*7 
ret 0 
_f1 ENDP 
; a*28 
_a$ = 8 
_f2 PROC 
mov ecx, DWORD PTR a$[esp-4] 
; ECX=a 
lea eax, DWORD PTR [ecx*8] 
; EAX=ECX*8 
sub eax, ecx 
; EAX=EAX-ECX=ECX*8 - ECX=ECX*7=a*7 
shl eax, 2 
; EAX=EAX<<2=(a*7)*4=a*28 
ret 0 
_f2 ENDP 
; a*17 
_a$ = 8 
_f3 PROC 
mov eax, DWORD PTR a$[esp-4] 
; EAX=a 
shl eax, 4 
; EAX=EAX<<4=EAX*1l6=a*16 
add eax, DWORD PTR a$[esp-4] 
; EAX=EAX+a=a*16+a=a*17 
ret 0 
_ 3 ENDP 
ARM 


Keil pour le mode ARM tire partie du décalage de registre du second opérande: 


Listing 1.198 : avec optimisation Keil 6/2013 (Mode ARM) 


; a*7 
|| 1] | PROC 

RSB r0,r0,r0,LSL #3 
; RO=RO<<3 - RO=R0*8 - RO=a*8 - a=a*7 
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BX lr 
ENDP 
; a*28 
|| f2|] PROC 
RSB r0,r0,r0,LSL #3 
; RO=RO<<3 - RO=R0*8 - RO=a*8 - a=a*7 
LSL r0,r0,#2 
; RO=RO<<2=R0*4=a*7*4=a*28 
BX lr 
ENDP 
; a*17 
|| f3|] PROC 
ADD r0,r0,r0,LSL #4 
; RO=RO+RO<<4=R0O+R0*16=R0*17=a*17 
BX lr 
ENDP 


Mais ce n'est pas disponible en mode Thumb. II ne peut donc pas l'optimiser: 


Listing 1.199 : avec optimisation Keil 6/2013 (Mode Thumb) 


; a*7 
|| f1|]| PROC 

LSLS r1,r0,#3 
; R1=RO0<<3=a<<3=a*8 

SUBS ro,r1,ro 
; RO=R1-RO=a*8 - a=a*7 

BX lr 

ENDP 
; a*28 
|| f2|] PROC 

MOVS r1,*0xlc ; 28 
; R1=28 

MULS ro,r1,ro 
; RO=R1*RO=28*a 

BX lr 

ENDP 
; a*17 
|| f3|] PROC 

LSLS r1,r0,#4 
; R1=RO<<4=R0*16=a*16 

ADDS r0,r0,r1 
; RO=RO+R1=a+a*16=a*17 

BX lr 

ENDP 


MIPS 
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Listing 1.200 : GCC 4.4.5 avec optimisation (IDA) 


fl: 
sll $v0, $a0, 3 
; $vO = $a0<<3 = $a0*8 
jr $ra 
subu $v0, $a0 ; branch delay slot 
; $vO = $v0-$a0 = $a0*8-$a0 = $a0*7 
_f2: 
sll $v0, $a0, 5 
; $vO = $a0««5 = $a0*32 
sll $a0, 2 
; $a0 = $a0<<2 = $a0*4 
jr $ra 
subu $v0, $a0 ; branch delay slot 
; $v0 = $a0*32-$a0*4 - $a0*28 
f3: 
sll $v0, $a0, 4 
; $vO = $a0<<4 = $a0*16 
jr $ra 
addu $v0, $a0 ; branch delay slot 
; $vO = $a0*16+$a0 = $a0*17 
64-bit 


#include <stdint.h> 


int64 t fl(int64 t a) 
1 

return a*7; 
s 
int64 t f2(int64 t a) 
1 

return a*28; 
}; 
int64 t f3(int64 t a) 
{ 

return a*17; 
}; 
x64 

Listing 1.201 : MSVC 2012 avec optimisation 
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lea rax, [0+rdi*8] 
; RAX=RDI*8=a*8 
sub rax, rdi 
; RAX=RAX-RDI=a*8 -a=a*7 
ret 
a*28 
f2: 
lea rax, [0+rdi*4] 
; RAX=RDI*4=a*4 
sal rdi, 5 
; RDI=RDI<<5=RDI*32=a*32 
sub rdi, rax 
; RDI=RDI -RAX=a*32-a*4=a*28 
mov rax, rdi 
ret 
; a*17 
f3: 
mov rax, rdi 
sal rax, 4 
; RAX=RAX<<4=a*16 
add rax, rdi 
; RAX=a*16+a=a*17 
ret 
ARM64 


GCC 4.9 pour ARM64 est aussi concis, gráce au modificateur de décalage: 


Listing 1.202 : GCC (Linaro) 4.9 avec optimisation ARM64 


; a*7 
f1: 
Isl x1, x0, 3 
; X1=X0<<3=X0*8=a*8 
sub x0, x1, x0 
; XO=X1-X0=a*8-a=a*7 
ret 
; a*28 
f2: 
Isl x1, x0, 5 
; X1=X0<<5=a*32 
sub x0, x1, x0, lsl 2 
; X0=X1-X0<<2=a*32 - a<<2=a*32 - a*4=a*28 
ret 
; a*17 
f3: 
add x0, x0, x0, isl 4 


; X0=X0+X0<<4=a+a*16=a*17 
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ret 


Algorithme de multiplication de Booth 


Il fût un temps où les ordinateurs étaient si gros et chers, que certains d'entre eux 
ne disposaient pas de la multiplication dans le CPU, comme le Data General Nova. 
Et lorsque l'on avait besoin de l'opérateur de multiplication, il pouvait étre fourni 
au niveau logiciel, par exemple, en utilisant l'algorithme de multiplication de Booth. 
C'est un algorithme de multiplication qui utilise seulement des opérations d'addition 
et de décalage. 


Ce que les optimiseurs des compilateurs modernes font n'est pas la méme chose, 
mais le but (multiplication) et les ressources (des opérations plus rapides) sont les 
mémes. 


1.24.2 Division 
Division en utilisant des décalages 


Exemple de division par 4: 


unsigned int f(unsigned int a) 


1 
}; 


return a/4; 


Nous obtenons (MSVC 2010) : 
Listing 1.203 : MSVC 2010 


_a$ = 8 ; size = 4 
f PROC 
mov eax, DWORD PTR a$[esp-4] 
shr eax, 2 
ret 0 
f ENDP 


L'instruction SHR (SHift Right décalage à droite) dans cet exemple décale un nombre 
de 2 bits vers la droite. Les deux bits libérés à gauche (i.e., les deux bits les plus 
significatifs) sont mis à zéro. Les deux bits les moins significatifs sont perdus. En fait, 
ces deux bits perdus sont le reste de la division. 


L'instruction SHR fonctionne tout comme SHL, mais dans l'autre direction. 


ANNOS CORO 
Es OBRAR 
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Il est facile de comprendre si vous imaginez le nombre 23 dans le systéme décimal. 
23 peut étre facilement divisé par 10, juste en supprimant le dernier chiffre (3—le 
reste de la division). Il reste 2 aprés l'opération, qui est le quotient. 


Donc, le reste est perdu, mais c'est OK, nous travaillons de toutes facons sur des 
valeurs entiéres, ce sont sont pas des nombres réels! 


Division par 4 en ARM: 
Listing 1.204 : sans optimisation Keil 6/2013 (Mode ARM) 


f PROC 
LSR r0,r0,#2 
BX lr 
ENDP 


Division par 4 en MIPS: 
Listing 1.205 : GCC 4.4.5 avec optimisation (IDA) 


jr $ra 
srl $v0, $a0, 2 ; slot de délai de branchement 


L'instruction SLR est «Shift Right Logical » (décalage logique à droite). 


1.24.3 Exercice 
* http://challenges.re/59 


1.25 Unité à virgule flottante 

Le FPU est un dispositif à l'intérieur du CPU, spécialement concu pour traiter les 
nombres à virgules flottantes. 

Il était appelé «coprocesseur» dans le passé et il était en dehors du CPU. 


1.25.1 IEEE 754 


Un nombre au format IEEE 754 consiste en un signe, un significande (aussi appelé 
fraction) et un exposant. 


1.25.2 x86 


Ca vaut la peine de jeter un oeil sur les machines à base de piles ou d'apprendre les 
bases du langage Forth, avant d'étudier le FPU en x86. 


Il est intéressant de savoir que dans le passé (avant le CPU 80486) le coprocesseur 
était une puce séparée et n'était pas toujours préinstallé sur la carte mère. Il était 
possible de l'acheter séparément et de l'installer!??. 


109Par exemple, John Carmack a utilisé des valeurs arithmétiques à virgule fixe dans son jeu vidéo Doom, 
stockées dans des registres 32-bit GPR (16 bit pour la partie entiére et 16 bit pour la partie fractionnaire), 
donc Doom pouvait fonctionner sur des ordinateurs 32-bit sans FPU, i.e., 80386 et 80486 SX. 
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A partir du CPU 80486 DX, le FPU est intégré dans le CPU. 


L'instruction FWAIT nous rappelle le fait qu'elle passe le CPU dans un état d'attente, 
jusqu'à ce que le FPU ait fini son traitement. 


Un autre rudiment est le fait que les opcodes d'instruction FPU commencent avec 
ce qui est appelé l'opcode-«d'échappement » (D8. .DF), i.e., opcodes passés à un 
coprocesseur séparé. 


Le FPU a une pile capable de contenir 8 registres de 80-bit, et chaque registre peut 
contenir un nombre au format IEEE 754. 


Ce sont ST(0)..ST(7). Par concision, IDA et OllyDbg montrent ST(0) comme ST, qui 
est représenté dans certains livres et manuels comme «Stack Top ». 


1.25.3 ARM, MIPS, x86/x64 SIMD 


En ARM et MIPS le FPU n'a pas de pile, mais un ensemble de registres, qui peuvent 
étre accédés aléatoirement, comme GPR. 


La méme idéologie est utilisée dans l'extension SIMD des CPUs x86/x64. 


1.25.4 C/C++ 


Le standard des langages C/C++ offre au moins deux types de nombres à virgule 
flottante, float (simple-précision, 32 bits) 11° et double (double-précision, 64 bits). 


Dans [Donald E. Knuth, The Art of Computer Programming, Volume 2, 3rd ed., (1997)246] 
nous pouvons trouver que simple-précision signifie que la valeur flottante peut étre 
stockée dans un simple mot machine [32-bit], double-précision signifie qu'elle peut 
étre stockée dans deux mots (64 bits). 


GCC supporte également le type long double (précision étendue, 80 bit), que MSVC 
ne supporte pas. 


Le type float nécessite le même nombre de bits que le type int dans les environne- 
ments 32-bit, mais la représentation du nombre est complétement différente. 


1.25.5 Exemple simple 


Considérons cet exemple simple: 


#include <stdio.h> 
double f (double a, double b) 
{ 

return a/3.14 + b*4,1; 
}; 
int main() 
1 


110le format des nombres à virgule flottante simple précision est aussi abordé dans la section Travailler 
avec le type float comme une structure (1.30.6 on page 481) 
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printf ("SfAn", f(1.2, 3.4)); 
}; 


x86 
MSVC 


Compilons-le avec MSVC 2010: 
Listing 1.206 : MSVC 2010: f() 


CONST SEGMENT 

. reale4010666666666666 DQ 04010666666666666r ; 4.1 
CONST ENDS 

CONST SEGMENT 

__real@40091eb851eb851f DQ 040091eb851eb851fr ; 3.14 
CONST ENDS 

_ TEXT SEGMENT 


_a$ = 8 ; size = 8 
_b$ = 16 ; size = 8 
f PROC 
push ebp 
mov ebp, esp 


fld QWORD PTR a$[ebp] 

; état courant de la pile: ST(0) = a 
fdiv | QWORD PTR  realQ40091eb851eb851f 

; état courant de la pile: ST(0) = résultat de a divisé par 3.14 
fld QWORD PTR b$[ebp] 


; état courant de la pile: ST(0) = b; 
; ST(1) = résultat de a divisé par 3.14 


fmul  QWORD PTR _ real@4010666666666666 
; état courant de la pile: 
; ST(0) = résultat de b * 4.1; 
; ST(1) = résultat de a divisé par 3.14 
faddp ST(1), ST(0) 


; état courant de la pile: ST(0) = résultat de l'addition 


pop ebp 
ret 0 
_f ENDP 


FLD prend 8 octets depuis la pile et charge le nombre dans le registre ST(0), 


en 
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le convertissant automatiquement dans le format interne sur 80-bit (précision éten- 
due) : 


FDIV divise la valeur dans ST(0) par le nombre stocké a l'adresse 

| realQ40091eb851eb851f —la valeur 3.14 est encodée ici. La syntaxe assembleur 
ne supporte pas les nombres à virgule flottante, donc ce que l'on voit ici est la re- 
présentation hexadécimale de 3.14 au format 64-bit IEEE 754. 


Aprés l'exécution de FDIV, ST(0) contient le quotient. 


À propos, il y a aussi l'instruction FDIVP, qui divise ST(1) par ST(0), prenant ces 
deux valeurs dans la pile et poussant le résultant. Si vous connaissez le langage 
Forth, vous pouvez comprendre rapidement que ceci est une machine à pile. 


L'instruction FLD subséquente pousse la valeur de b sur la pile. 
Après cela, le quotient est placé dans ST(1), et ST(0) a la valeur de b. 


L'instruction suivante effectue la multiplication: b de ST(0) est multiplié par la valeur 
en 

. real4010666666666666 (le nombre 4.1 est là) et met le résultat dans le registre 
ST(0). 


La derniére instruction FADDP ajoute les deux valeurs au sommet de la pile, stockant 
le résultat dans ST(1) et supprimant la valeur de ST(0), laissant ainsi le résultat au 
sommet de la pile, dans ST(0). 


La fonction doit renvoyer son résultat dans le registre ST(0), donc il n'y a aucune 
autre instruction aprés FADDP, excepté l'épilogue de la fonction. 
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MSVC + OllyDbg 


2 paires de mots 32-bit sont marquées en rouge sur la pile. Chaque paire est un 
double au format IEEE 754 et est passée depuis main(). 


Nous voyons comment le premier FLD charge une valeur (1.2) depuis la pile et la 
stocke dans ST(0) : 


CPU - main thread, mo i loj xl 
: ^ 
: D 


LARG. 13 x 2020284 
een E 
a FLOAT BB16F9RC 
6G16F9AC 
26882801 
GGFF3388 


DOFF1006 mple.G@FF1 


bit B(FFFFFFFF) 
BL FFFFFFFF) 
BL FFFFFFFF) 
B(FFFFFFFF) 
TEFDDaaatFFF) 

bit @(FFFFFFFF) 


LastErr 86860806 ERROR 


PTR D: FLOAT 
: ? 28828286 (NO, MB, NE 


) PTR 
FLORT 


8 
Prec NEAR,S3 Mask 
Last cmnd 0023:00FF1003 simple.8 


mmmmmmmmmmmmmmmmmTm 


Fig. 1.62: OllyDbg : le premier FLD a été exécuté 


À cause des inévitables erreurs de conversion depuis un nombre flottant 64-bit au 
format IEEE 754 vers 80-bit (utilisé en interne par le FPU), ici nous voyons 1.199..., 
qui est proche de 1.2. 


EIP pointe maintenant sur l'instruction suivante (FDIV), qui charge un double (une 
constante) depuis la mémoire. Par commodité, OllyDbg affiche sa valeur: 3.14 
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Continuons l'exécution pas à pas. FDIV a été exécuté, maintenant ST(0) contient 
0.382...(quotient) : 


CPU - main thread, module simple 


aarriaoaoa|rs PUSH EBP Rea z P 
QGFF 1901 MOU EBP,ESP AX OB2D2848 
3 FLD GUORD PTR SS: CARG. 1] ! 6E494714 ASCII "H(-" 
DIU SWORD PTR, DS: LAFF 20002 ELOAT 00080088 NN 
1 H n i A ^ 
FMUL_QUORD PTR DS: LOFF20C8] BB EF IRC 
GGFF 1915 FADDP ST(1),ST OBIEFSAC 
QOFF1G1 POP EBP 90000001 


INTS GGFF3388 simple. 0BFF3388 
INT3 BOFF1B90C simple. BOFF1DOC 


INTS C S B 32bit B(FFFFFFFF) 
INT3 , 1 it B(FFFFFFFF) 
INT3 : 1 t @(FFFFFFFF) 
ate s PS OS eee er rpDeL cr) 
3 > 3 3 t 1806 ( ) 
PUSH EBP = à 
MOU EBP,ESP : BC FFFFFFFF) 


SUB ESP, 2 000998 CESS 
DDOS EO20FFAI FLD GORD PTR DS: COFF20E8] PRECAOPA ERROR SUCCESS 


FSTP_QUORD PTR SS: [LOCAL. 2] 5 (HO, NB, NE, R, NS, PE, GE, G) 
SUB ESP,8 E 


n 
FLO QWORD PTR DS: COFF2008] 
FSTP QWORD PTR SS:CLOCAL.4] 
CALL aarFiaaa 

ADD ESP,S 

FSTP QWORD PTR SS:CLOCAL.2] 
PUSH OFFSET SOFF 2000 


“IU 


Y GU TImocogqcno: o^ 


GOFF 1G3B 
GOFF 18408 
GGFF 1843 
OOFF 1046 


mom m om om m m n n n ae 


empty 
6 empty 
empty 


DOODO 


321 Eu U 0 
3826 Cond 8 6 G B Err LE 
@27F Prec NEAR,S3 Mask” HH H 


SP 
51 
Last cmnd 0023:00FF1006 simple.G@FF 1986 


6 2 ‘Sem e 

3 2i ; z Ht- hN- e 

GüFF3040 > 
8 


GOFF3OSO RETURN from simpl: 


9016F 90 ASCII "pN-" 

16F9D4 

BOFF3090 SF? 

OBFF30A0| 60 ea a à 5 5 Eee 

BOFF3080| & 5 7 a| oo 60 ae oF? 

OBFF30CO 9916F9E0 

G@FF 3000 0016F3E4 

QOFF3GE0 a o eo IOE 2ER 

GOFF Sora z 2 2 BB16F9FG 
E 


Fig. 1.63: OllyDbg : FDIV a été exécuté 
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Troisième étape: le FLD suivant a été exécuté, chargeant 3.4 dans ST(0) (ici nous 
voyons la valeur approximative 3.39999...) : 


CPU - main thread, module simple 


55 PUSH EBP 

SBEC MOU EBP,ESP 

DD45 aes FLD QWORD PTR SS: LARG. 1] 
DC35 pa2arrot FDIU QUORD PTR DS: [OFF2000] 
FLO QWORD PTR SS: [ARG.3] 
FMUL GWORD PTR DS: [OFF2008] 
oe ipn test 


IP @GFF166F 


FFFFFFFF) 
FFFFFFFF) 
"EFDDBBatFFF) 

BCFFFFFFFF) 


e 


PUSH EBP 

MOU EBP,ESP 

SUB ESP,8 

DDOS EG2OFFOl FLO GWORD PTR DS:LOFF2GEO1 
BR SWORD PTR SS: [LOCAL.21 


FLO GUORD PTR DS: [OFF2008] 
FSTP QWORD PTR SS:CLOCAL.4] 
ES COFFFFFF | CALL aarrFiaaa 


OOANNDDO M 
cct 


wor m om tm om m n] n de 


83C4 a8 ADD ESP,8 
DD1C24 FSTP QWORD PTR SS: [LOCAL.2] 
68 GOSOFFOG | PUSH OFFSET 09FF3000 


CQGFF26C3 -100000000000000 
ST=3. 3999999999999999110 


RETURN from simpl: 
ASCII "phN-" 


mmmmmmmmmmmmmmmmTTT 


Fig. 1.64: OllyDbg : le second FLD a été exécuté 


En méme temps, le quotient est poussé dans ST(1). Exactement maintenant, EIP 
pointe sur la prochaine instruction: FMUL. Ceci charge la constante 4.1 depuis la 
mémoire, ce que montre OllyDbg. 
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Suivante: FMUL a été exécutée, donc maintenant le produit est dans ST(0) : 


CPU - main thread, module simple -{0/ x! 
- T 


aarriaoa|rs PUSH EBP gi 
BOFF1001 MOU EBP,ESP x aaeDes4s 
aaFFiaas FLO QWORD PTR SS: [ARG. 1] x 6E494714 ASCII "H(-" 


BOFF1006 DC35 

GOFF 1980 WOI S: LARG. 31 Ere ai 
OØFF100F D. Y Bal6Fonc 
OFF 1015 | EN FRDDP ST(1) FLORT ABLEFIAC 
GOFF1IG17 Baaaaoa! 


G6FF1918 E arra 
aarFioi19 GGFF3388 simple. BBFF3388 


DOFF1B1A BOFF1915 simple.GGFF1815 


GOFF1G1B ; Pe 
7 ‘ > S2bit Gl FFFFFFFF) 
BOFF 1810 3 3 S2bit G(FFFFFFFF) 
GOFF1G1E 32bit @(FFFFFFFF) 
GOFF1IGIF S2bit G(FFFFFFFF) 
OOFF1020 ] 32bit 7EFDDBOB(FFF) 
2 MOU EBP, ESP S 32bit BLFFFFFFFF) 
, 
SUB ESP,8 


zu 
a r pr a 5 S 
FLO GWORD PTR DS:[ØFF20E0] LastErr 96086806 ERROR SUCCESS 
FSTP_QUORD PTR SS: [LOCAL.2] 96960266 (NO,NB,NE,A,NS,PE,GE,G) 


GOFF 1926 
GOFF192C 
GOFF 1G2F SUB ESP,8 
GOFF1 FLO WORD PTR DS: COFF2008] 
GOFF 1038 FSTP QUORD PTR SS: LOCAL. 41 
ES COFFFFFF |CALL_GGFF 1000 
83c4 08 ADO ESP, 8 
DDÍC24 FSTP QWORD PTR SS:CLOCAL.2] 
eeFFic4e||- 68 6939FF09 | PUSH OFFSET GGFF 23000 . nory 
ST=13. 9399999999999977 30 T7 empty 


ST(1)=0.3821656050955413719 Sasa tado aoe. Ea 


B27F Prec NEAR,S3 Mask 


GOFF 1038 
GOFF 1648 
GOFF 1843 


mom om m om m m n n n n dn 


0016F 980 
Bal6F9B4 
G616F 988 
GG16F9BC 
aal6FSCü 
BaleF9C4 ü 
0016F9CS > RETURN from simpl: 
BBleF9CC 
aa1eF9DG ASCII "ph-" 
aa16F9D4 
aateF9De 
a16F90C 
GG16F9E6 
GG16F9E4 
GG16F9E8 
GG16F9EC 
d 5 BaleF9FG 
BBOFF3110 Foto 


Fig. 1.65: OllyDbg : FMUL a été exécuté 
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Suivante: FADDP a été exécutée, maintenant le résultat de l'addition est dans ST(0), 
et ST(1) est vidé. 


PUSH_EBP 

MOU EBP,ESP 

FLD GWORD PTR SS: CARG. 

FDIU QWORD PTR BS: LOF F 2900] 
FLO QWORD PTR_SS:CARG.3 

FMUL GWUORD PTR BS: CorF2aC8) 
FADDP ST(1),ST 

POP EBP 


SCII "H(-" 


simple. GFF 
> BOFF1917 simple.DOFF1D1 


it BLFFFFFFFF) 
it B(FFFFFFFF) 
it B(FFFFFFFF) 
it B(FFFFFFFF) 
it vEFDDaBatFFF) 
it GCFFFFFFFF) 


PUSH EBP 

MOU EBP,ESP 

SUB ESP, 8 

FLD QWORD PTR DS: [OFF20E6] 
FSTP_QWORD PTR SS:CLOCAL.2] 
SUB ESP,8 

FLD GUORD PTR DS: [OFF20D8] 
FSTP QWORD PTR SS:CLOCAL.4] 
ES COFFFFFF | CALL S6FF1900 

8304 a8 ADD ESP,8 

FSTP QWORD PTR SS:CLOCAL.2] 
PUSH OFFSET GOFF 3000 


Top of ‘stack TOGIEF AAC 1= 00167 504 
EBP=0016F9AC 


00-0ND00 m mmmmmmmis 


F 
F 
F 
F 
F 
F 
F 
[3 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 
F 


P 
18 
F 11 
cmnd boss: BBF ID1S simple. 28FF18 


RETURN from simpl 


RETURN from simpl 


ASCII "pN-" 


Fig. 1.66: OllyDbg : FADDP a été exécuté 


Le résultat est laissé dans ST(0), car la fonction renvoie son résultat dans ST(0). 
main() prend cette valeur depuis le registre plus loin. 


Nous voyons quelque chose d'inhabituel: la valeur 13.93...se trouve maintenant 
dans ST (7). Pourquoi? 


Comme nous l'avons lu il y a quelque temps dans ce livre, les registres FPU sont une 
pile: 1.25.2 on page 286. Mais ceci est une simplification. 


Imaginez si cela était implémenté en hardware comme cela est décrit, alors tout le 
contenu des 7 registres devrait étre déplacé (ou copié) dans les registres adjacents 
lors d'un push ou d'un pop, et ceci nécessite beaucoup de travail. 


En réalité, le FPU a seulement 8 registres et un pointeur (appelé TOP) qui contient 
un numéro de registre, qui est le «haut de la pile» courant. 


Lorsqu'une valeur est poussée sur la pile, TOP est déplacé sur le registre disponible 
suivant, et une valeur est écrite dans ce registre. 
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La procédure est inversée si la valeur est lue, toutefois, le registre qui a été libéré 
n'est pas vidé (il serait possible de le vider, mais ceci nécessite plus de travail qui 
peut dégrader les performances). Donc, c'est ce que nous voyons ici. 


On peut dire que FADDP sauve la somme sur la pile, et y supprime un élément. 
Mais en fait, cette instruction sauve la somme et ensuite décale TOP. 


Plus précisément, les registres du FPU sont un tampon circulaire. 
GCC 


GCC 4.4.1 (avec l'option -03) génére le méme code, juste un peu différent: 


Listing 1.207 : GCC 4.4.1 avec optimisation 


public f 
f proc near 
arg 0 = qword ptr 8 
arg 8 - qword ptr 10h 
push ebp 
fld ds:dbl 8048608 ; 3.14 


état de la pile maintenant: ST(0) = 3.14 


mov ebp, esp 
fdivr [ebp+arg_0] 


état de la pile maintenant: ST(0) = résultat de la division 


fld ds:dbl 8048610 ; 4.1 


état de la pile maintenant: ST(0) = 4.1, ST(1) = résultat de la division 


fmul [ebp+arg_8] 


; état de la pile maintenant: ST(0) = résultat de la multiplication, ST(1) = 
résultat de la division 


pop ebp 
faddp  st(1), st 


état de la pile maintenant: ST(0) - résultat de l'addition 


retn 
f endp 


La différence est que, tout d'abord, 3.14 est poussé sur la pile (dans ST(0)), et 
ensuite la valeur dans arg 60 est divisée par la valeur dans ST(0). 


FDIVR signifie Reverse Divide —pour diviser avec le diviseur et le dividende échan- 
gés l'un avec l'autre. Il n'y a pas d'instruction de ce genre pour la multiplication 
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puisque c'est une opération commutative, donc nous avons seulement FMUL sans 
son homologue -R. 


FADDP ajoute les deux valeurs mais supprime aussi une valeur de la pile. Aprés cette 
opération, ST(0) contient la somme. 


ARM: avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Jusqu'à la standardisation du support de la virgule flottante, certains fabricants de 
processeur ont ajouté leur propre instructions étendues. Ensuite, VFP (Vector Floa- 
ting Point) a été standardisé. 


Une différence importante par rapport au x86 est qu'en ARM, il n'y a pas de pile, 
vous travaillez seulement avec des registres. 


Listing 1.208 : avec optimisation Xcode 4.6.3 (LIVM) (Mode ARM) 


T 
VLDR D16, 23.14 
VMOV D17, RO, R1 ; charge "a" 
VMOV D18, R2, R3 ; charge "b" 
VDIV.F64 D16, D17, D16 ; a/3.14 
VLDR D17, =4.1 
VMUL. F64 D17, D18, D17 ; b*4.1 
VADD.F64 D16, D17, D16 ; + 
VMOV RO, R1, D16 
BX LR 
dbl 2C98 DCFD 3.14 ; DATA XREF: f 
dbl_2CA0 DCFD 4.1 ; DATA XREF: f+10 


Donc, nous voyons ici que des nouveaux registres sont utilisés, avec le préfixe D. 


Ce sont des registres 64-bits, il y en a 32, et ¡ls peuvent étre utilisés tant pour des 
nombres à virgules flottantes (double) que pour des opérations SIMD (c'est appelé 
NEON ici en ARM). 


Il y a aussi 32 S-registres 32 bits, destinés á étre utilisés pour les nombres a virgules 
flottantes simple précision (float). 


C'est facile à retenir: les registres D sont pour les nombres en double précision, tandis 
que les registres S—-pour les nombres en simple précision Pour aller plus loin: .2.3 
on page 1350. 


Les deux constantes (3.14 et 4.1) sont stockées en mémoire au format IEEE 754. 


VLDR et VMOV, comme il peut en étre facilement déduit, sont analogues aux instruc- 
tions LDR et MOV, mais travaillent avec des registres D. 


Il est à noter que ces instructions, tout comme les registres D, sont destinées non 
seulement pour les nombres à virgules flottantes, mais peuvent aussi étre utilisées 
pour des opérations SIMD (NEON) et cela va étre montré bientót. 


Les arguments sont passés à la fonction de maniére classique, via les R-registres, 
toutefois, chaque nombre en double précision a une taille de 64 bits, donc deux 
R-registres sont nécessaires pour passer chacun d'entre eux. 
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VMOV D17, RO, R1 au début, combine les deux valeurs 32-bit de RO et R1 en une 
valeur 64-bit et la sauve dans D17. 


VMOV RO, R1, D16 est l'opération inverse: ce qui est dans D16 est séparé dans deux 
registres, RO et R1, car un nombre en double précision qui nécessite 64 bit pour le 
stockage, est renvoyé dans RO et R1. 


VDIV, VMUL and VADD, sont des instructions pour traiter des nombres à virgule flot- 
tante, qui calculent respectivement le quotient, produit et la somme. 


Le code pour Thumb-2 est similaire. 


ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


f 
PUSH {R3-R7,LR} 
MOVS R7, R2 
MOVS R4, R3 
MOVS R5, RO 


LDR R2, =0x66666666 ; 4.1 
LDR R3, =0x40106666 

MOVS RO, R7 

MOVS R1, R4 

BL . aeabi dmul 

MOVS R7, RO 

MOVS RA, R1 

LDR R2, =0x51EB851F ; 3.14 
LDR R3, =0x40091EB8 

MOVS RO, R5 

MOVS R1, R6 

BL . aeabi ddiv 

MOVS R2, R7 

MOVS R3, R4 


BL . aeabi dadd 

POP {R3-R7,PC} 
; 4.1 au format IEEE 754: 
dword 364 DCD 0x66666666 ; DATA XREF: f+A 
dword 368 DCD 0x40106666 ; DATA XREF: f+C 
; 3.14 au format IEEE 754: 
dword 36C DCD 0x51EB851F ; DATA XREF: f+1A 
dword 370 DCD 0x40091EB8 ; DATA XREF: f+1C 


Code généré par Keil pour un processeur sans FPU ou support pour NEON. 


Les nombres en virgule flottante double précision sont passés par des R-registres 
génériques et au lieu d'instructions FPU, des fonctions d'une bibliothéque de service 
sont appelées (comme . aeabi dmul,  aeabi ddiv,  aeabi dadd) qui émulent 
la multiplication, la division et l'addition pour les nombres à virgule flottante. 


Bien súr, c'est plus lent qu'un coprocesseur FPU, mais toujours mieux que rien. 
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À propos, de telles bibliothéques d'émulation de FPU étaient trés populaires dans 
le monde x86 lorsque les coprocesseurs étaient rares et chers, et étaient installés 
seulement dans des ordinateurs coüteux. 


L'émulation d'un coprocesseur FPU est appelée soft float ou armel (emulation) dans 
le monde ARM, alors que l'utilisation des instructions d'un coprocesseur FPU est 
appelée hard float ou armhf. 

ARM64: GCC avec optimisation (Linaro) 4.9 


Code trés compact: 


Listing 1.209 : GCC avec optimisation (Linaro) 4.9 


f: 
; DO =a, D1 = b 

ldr d2, .LC25 253 14 
; D2 = 3.14 


fdiv dO, dQ, d2 
; DO = DO/D2 = a/3.14 

ldr d2, .LC26 ; 4.1 
; D2 = 4.1 

fmadd d0, dl, d2, dO 
; DO = D1*D2+D0 = b*4,1+a/3.14 

ret 


; constantes au format IEEE 754: 

.LC25: 
.word 1374389535 ; 3.14 
.word 1074339512 

.LC26: 
.word 1717986918 ; 4.1 
.word 1074816614 


ARM64: GCC sans optimisation (Linaro) 4.9 


Listing 1.210 : GCC sans optimisation (Linaro) 4.9 


f: 
sub sp, sp, £16 
str dO, [sp,8] ; sauve "a" dans le Register Save Area 
str dl, [sp] ; sauve "b" dans le Register Save Area 
ldr xl, [sp,8] 

; X1 = à 
ldr x0, .LC25 

; X0 = 3.14 


fmov dO, x1 
fmov dl, x0 
; DO = a, D1 = 3.14 
fdiv dO, dO, dl 
a/3.14 


© 
© 
l 
J 
© 
jes 
© 
pa 
Il 


fmov x1, d0 
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; X1 = a/3.14 

ldr x2, [sp] 
z X2 = b 

ldr x0, .LC26 
; XO = 4.1 

fmov dO, x2 
; DO = b 

fmov dl, x0 
Dl: = 4,1 


fmul dO, dO, dl 
; DO = DO*D1 = b*4.1 


fadd dO, dQ, dl 
; DO = DO+D1 = a/3.14 + b*4.1 


fmov x0, dO ; \ code redondant 
fmov d0, x0 ; / 
add sp, sp, 16 
ret 

.LC25: 
.word 1374389535 ; 3.14 
.word 1074339512 

.LC26: 


.word 1717986918 ; 4.1 
.word 1074816614 


GCC sans optimisation est plus verbeux. 


Il y a des nombreuses modifications de valeur inutiles, incluant du code clairement 
redondant (les deux derniéres instructions FMOV). Sans doute que GCC 4.9 n'est pas 
encore trés bon pour la génération de code ARM64. 


Il est utile de noter qu'ARM64 posséde des registres 64-bit, et que les D-registres 
sont aussi 64-bit. 


Donc le compilateur est libre de sauver des valeurs de type double dans GPRs au 
lieu de la pile locale. Ce n'est pas possible sur des CPUs 32-bit. 


Et encore, à titre d'exercice, vous pouvez essayer d'optimiser manuellement cette 
fonction, sans introduire de nouvelles instructions comme FMADD. 


1.25.6 Passage de nombres en virgule flottante par les argu- 
ments 


#include <math.h> 
#include <stdio.h> 
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int main () 


1 
printf ("32.01 ^ 1.54 = %lf\n", pow (32.01,1.54)); 
return 0; 

} 

x86 


Regardons ce que nous obtenons avec MSVC 2010: 


Listing 1.211 : MSVC 2010 


CONST SEGMENT 

__real@40400147ae147ael DQ 040400147ae147aelr ; 32.01 
. reale3ff8a3d70a3d70a4 DQ 03ff8a3d70a3d70a4r ; 1.54 
CONST ENDS 


main PROC 
push ebp 
mov ebp, esp 
sub esp, 8 ; allouer de l'espace pour la premiére variable 
fld QWORD PTR _ real@3ff8a3d70a3d70a4 
fstp QWORD PTR [esp] 
sub esp, 8 ; allouer de l'espace pour la seconde variable 
fld QWORD PTR _ real@40400147ae147ael 
fstp QWORD PTR [esp] 
call | pow 
add esp, 8 ; rendre l'espace d'une variable. 


; sur la pile locale, il y a ici encore 8 octets réservés pour nous. 
; le résultat se trouve maintenant dans ST(0) 


; déplace le résultat de ST(0) vers la pile locale pour printf(): 
fstp QWORD PTR [esp] 
push OFFSET $SG2651 
call printf 
add esp, 12 


xor eax, eax 
pop ebp 
ret 0 

main ENDP 


FLD et FSTP déplacent des variables entre le segment de données et la pile du FPU. 
pow()*!! prend deux valeurs depuis la pile et renvoie son résultat dans le registre 
ST(0). printf() prend 8 octets de la pile locale et les interpréte comme des va- 


riables de type double. 


À propos, une paire d'instructions MOV pourrait étre utilisée ici pour déplacer les 
valeurs depuis la mémoire vers la pile, car les valeurs en mémoire sont stockées au 


lllune fonction C standard, qui élève un nombre à la puissance donnée (puissance) 
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format IEEE 754, et pow() les prend aussi dans ce format, donc aucune conversion 
n'est nécessaire. C'est fait ainsi dans l'exemple suivant, pour ARM: 1.25.6. 


ARM + sans optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


main 
var C = -0xC 
PUSH {R7, LR} 
MOV R7, SP 
SUB SP, SP, #4 
VLDR D16, =32.01 
VMOV RO, R1, D16 
VLDR D16, =1.54 
VMOV R2, R3, D16 
BLX _ pow 
VMOV D16, RO, R1 
MOV RO, OxFC1 ; "32.01 ^ 1.54 = %lf\n" 
ADD RO, PC 
VMOV R1, R2, D16 
BLX | printf 
MOVS R1, 0 
STR RO, [SP,#0xC+var C] 
MOV RO, R1 
ADD SP, SP, #4 
POP {R7, PC} 
dbl_2F90 DCFD 32.01 ; DATA XREF: _main+6 
dbl_2F98 DCFD 1.54 ; DATA XREF: _main+E 


Comme nous l'avons déjà mentionné, les pointeurs sur des nombres flottants 64-bit 
sont passés dans une paire de R-registres. 


Ce code est un peu redondant (probablement car l'optimisation est désactivée), puis- 
qu'il est possible de charger les valeurs directement dans les R-registres sans tou- 
cher les D-registres. 


Donc, comme nous le voyons, la fonction pow recoit son premier argument dans RO 
et R1, et le second dans R2 et R3. La fonction laisse son résultat dans RO et R1. Le 
résultat de pow est déplacé dans D16, puis dans la paire R1 et R2, d'où printf() 
prend le nombre résultant. 


ARM + sans optimisation Keil 6/2013 (Mode ARM) 


main 
STMFD SP!, {R4-R6,LR} 
LDR R2, =0xA3D70A4 ; y 
LDR R3, =0x3FF8A3D7 
LDR RO, =0xAE147AE1 ; x 
LDR R1, =0x40400147 


BL pow 
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MOV R4, RO 

MOV R2, R4 

MOV R3, R1 

ADR RO, a32 011 54Lf ; "32.01 ^ 1.54 = %lf\n" 

BL __2printf 

MOV RO, #0 

LDMFD SP!, {R4-R6,PC} 
y DCD 0xA3D70A4 ; DATA XREF: _main+4 
dword_520 DCD Ox3FF8A3D7 ; DATA XREF: _main+8 
x DCD OxAE147AE1 ; DATA XREF: _main+C 


dword 528 DCD 0x40400147 ; DATA XREF: main+10 
a32 011 54Lf DCB "32.01 ^ 1.54 = %lf",0xA,0 
; DATA XREF: main+24 


Les D-registres ne sont pas utilisés ici, juste des paires de R-registres. 


ARM64 + GCC (Linaro) 4.9 avec optimisation 


Listing 1.212 : GCC (Linaro) 4.9 avec optimisation 


f: 
stp x29, x30, [sp, -16]! 
add x29, sp, 0 
ldr dl, .LC1 ; charger 1.54 dans D1 
ldr dO, .LCO ; charger 32.01 dans DO 
bl pow 


; résultat de pow() dans DO 
adrp x0, .LC2 


add x0, x0, :lo12:.LC2 
bl printf 

mov w0, 0 

ldp x29, x30, [sp], 16 
ret 


.LC0: 
; 32.01 au format IEEE 754 
.word -1374389535 
.word 1077936455 
.LC1: 
; 1.54 au format IEEE 754 
.word 171798692 
.word 1073259479 
.LC2: 
.string "32.01 ^ 1.54 = %lf\n" 


Les constantes sont chargées dans DO et D1 : pow() les prend d'ici. Le résultat sera 
dans DO après l'exécution de pow(). Il est passé à printf () sans aucune modification 
ni déplacement, car printf() prend ces arguments de type intégral et pointeurs 
depuis des X-registres, et les arguments en virgule flottante depuis des D-registres. 


1.25.7 Exemple de comparaison 
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#include <stdio.h> 


double d max (double a, double b) 


{ 
if (a>b) 
return a; 
return b; 
}; 
int main() 
{ 
printf ("%f\n", d max (1.2, 3.4)); 
printf ("%f\n", d max (5.6, -4)); 
}; 


Malgré la simplicité de la fonction, il va être difficile de comprendre comment elle 
fonctionne. 


x86 


MSVC sans optimisation 


MSVC 2010 génere ce qui suit: 
Listing 1.213 : MSVC 2010 sans optimisation 


PUBLIC _d max 
_TEXT SEGMENT 
_a$ = 8 ; size = 8 
_b$ = 16 ; size = 8 
_d max PROC 

push ebp 

mov ebp, esp 


fld  QWORD PTR b$[ebp] 


; état courant de la pile: ST(0) = b 
; comparer b (ST(0)) et a, et dépiler un registre 


fcomp QWORD PTR a$[ebp] 


; la pile est vide ici 


fnstsw ax 
test ah, 5 
jp SHORT $LN1Gd max 


; nous sommes ici seulement si if a>b 


fld QWORD PTR a$[ebp] 
jmp SHORT $LN2Gd max 
$LN1@d_max: 
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fld  QWORD PTR b$[ebp] 


$LN2Gd max: 
pop ebp 
ret 0 
_d max ENDP 


Ainsi, FLD charge b dans ST(0). 


FCOMP compare la valeur dans ST(0) avec ce qui est dans a et met les bits C3/C2/CO 
du mot registre d'état du FPU, suivant le résultat. Ceci est un registre 16-bit qui 
refléte l'état courant du FPU. 


Aprés que les bits ont été mis, l'instruction FCOMP dépile une variable depuis la pile. 
C'est ce qui la différencie de FCOM, qui compare juste les valeurs, laissant la pile dans 
le méme état. 


Malheureusement, les CPUs avant les Intel P6??? ne possèdent aucune instruction de 
saut conditionnel qui teste les bits C3/C2/C0. Peut-étre est-ce une raison historique 
(rappel: le FPU était une puce séparée dans le passé). Les CPU modernes, à partir 
des Intel P6 possédent les instructions 

FCOMI/FCOMIP/FUCOMI/FUCOMIP —qui font la méme chose, mais modifient les flags 
ZF/PF/CF du CPU. 


L'instruction FNSTSW copie le le mot du registre d'état du FPU dans AX. Les bits 
C3/C2/CO sont placés aux positions 14/10/8, ils sont à la méme position dans le re- 
gistre AX et tous sont placés dans la partie haute de AX —AH. 


* Sib> a dans notre exemple, alors les bits C3/C2/C0 sont mis comme ceci: 0, O, 
0. 


* Si a» b, alors les bits sont: O, O, 1. 
e Si a=b, alors les bits sont: 1, 0, O. 
Si le résultat n'est pas ordonné (en cas d'erreur), alors les bits sont: 1, 1, 1. 
Voici comment les bits C3/C2/C0 sont situés dans le registre AX : 


14 10 9 8 


c3 C2C1CQ 


Voici comment les bits C3/C2/C0 sont situés dans le registre AH : 


6 2 1 0 


C3 C2C1CO 


Aprés l'exécution de test ah, 51%, seul les bits CO et C2 (en position O et 2) sont 
considérés, tous les autres bits sont simplement ignorés. 


Parlons maintenant du parity flag (flag de parité), un autre rudiment historique re- 
marquable. 


Ce flag est mis à 1 si le nombre de un dans le résultat du dernier calcul est pair, et 
à O s'il est impair. 


12|nte| P6 comprend les Pentium Pro, Pentium Il, etc. 
1135=101b 
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Regardons sur Wikipédia?** : 


Une raison commune de tester le bit de parité n'a rien á voir avec 
la parité. Le FPU posséde quatre flags de condition (CO à C3), mais ils 
ne peuvent pas étre testés directement, et doivent d'abord étre copiés 
dans le registre d'états. Lorsque ca se produit, CO est mis dans le flag 
de retenue, C2 dans le flag de parité et C3 dans le flag de zéro. Le 
flag C2 est mis lorsque e.g. des valeurs en virgule flottantes incompa- 
rable (NaN ou format non supporté) sont comparées avec l'instruction 
FUCOM. 


Comme indiqué dans Wikipédia, le flag de parité est parfois utilisé dans du code FPU, 
voyons comment. 


Le flag PF est mis à 1 si à la fois CO et C2 sont mis à 0 ou si les deux sont à 1, auquel 
cas le JP (jump if PF==1) subséquent est déclenché. Si l'on se rappelle les valeurs 
de C3/C2/C0 pour différents cas, nous pouvons voir que le saut conditionnel JP est 
déclenché dans deux cas: si b > a ou a = b (le bit C3 n'est pris en considération ici, 
puisqu'il a été mis à O par l'instruction test ah, 5). 


C'est trés simple ensuite. Si le saut conditionnel a été déclenché, FLD charge la 
valeurde b dans ST(0), et sinon, la valeur de a est chargée ici. 


Et à propos du test de C2? 
Le flag C2 est mis en cas d'erreur (NaN, etc.), mais notre code ne le teste pas. 


Si le programmeur veut prendre en compte les erreurs FPU, il doit ajouter des tests 
supplémentaires. 


lM4https://en.wikipedia.org/wiki/Parity flag 
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Premier exemple sous OllyDbg : a=1.2 et b=3.4 


Chargeons l'exemple dans OllyDbg : 


CPU - main ead, module d 


PUSH EBP 

MOU EBP,ESP 

FLO QWORD PTR SS:LRRG.31 
FCOMP QUORD PTR SS: CARG. 11] 
FSTSU AX 

TEST RH,685 

JPE SHORT Garciais 

FLO QUORD PTR SS:LRRG.11 
JMP SHORT G@FC1918 

FLO QUORD PTR SS:LRRG.31 


B(FFFFFFFF) 
7EFODGG6( FFF) 
GCFFFFFFFF) 


ODA 


PUSH_EBP 

MOU EBP,ESP 

SUB ESP,8 

FLD QWORD PTR DS: [OFC20E6] 
FSTP_QUORD PTR SS:CLOCAL.2] 
SUB ESP,8 

FLO QWORD PTR DS: (@FC2608] 
FSTP QWORD PTR SS:CLOCAL.4] 
CALL eer eee 


sr 


Sada | GG41FEF 4) Lap 
SUR EE Va RETURN from d_max 


25 A A 
FF FF FF FF FF FF FF FF 
FE FF FF FF øi et iex 


8 
HE4 hh 


RETURN from d mas 


Fig. 1.67: OllyDbg : la premiére instruction FLD a été exécutée 


Arguments courants de la fonction: a — 1.2 et b — 3.4 (Nous pouvons les voir dans la 
pile: deux paires de valeurs 32-bit). b (3.4) est déjà chargé dans ST(0). Maintenant 
FCOMP est train d'étre exécutée. OllyDbg montre le second argument de FCOMP, qui 
se trouve sur la pile à ce moment. 
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FCOMP a été exécutée: 


CPU - main thread, module d m al ES 
l PS 


HOU EBP, ESP = : 

A 00192848 

FLO QUORD PTR SS: [ARG. 31 ; 8 , 
FCOMP QUORD PTR SS:CARG.11 & ea 'SVCR10D. — in itenv 
— 60000000 


TEST AH, 05 ‘ 
JPE SHORT @GFC1615 864 IFEDE 


FLD QUORD Pin Tgirrna- td SI 000900091 


JHP SHORT 29 RE nul DOFC3SO 
FLD QUORD PTR SS: CARG.3] POF C3999 dms. er Cases 
GB8FC1809 d man. DOFC1BD9 


S 0928 32bit G(FFFFFFFF) 
Gaz Sebit OlFFFFFFFF) 

: aae bit ) 
Cane 002B 32bit OLFFFFFFFF) 
SERRE 8653 32bit 7EFDDOGO(FFF) 
x p 0028 32bit O(FFFFFFFF) 


EDU EBD LESA à LastErr 0000000 ERROR SUCCESS 

SUB ESP,8 00809206 (NO,NB, NE, R, NS, PE, GE, G 

FLO GWORD PTR DS: LOFC29E0] sotu 0 

FSTP QUORD PTR SS: LOCAL. 2] empty de 
empty à 


FSTP QUORD PTR SS:CLOCAL.4] empty 


empty 
ES COFFFFFF | CALL aarciaaa empty 


a 8304 08 ADD ESP empty 

FST=0000 (C3-8 C2=6 CI=6 CO-8 ES- Tr ORES á a i PUOZD 
AX=2848 paBa D 660684 
FCW @27F Reo Mask 11111 
Last cmnd 0023: 00FC1006 d_max. DOFC1006 v 


wo m om m on arr 
< 


< 


yv. 


aarcia 
99FC192F 


5 


D či- 
H(+ hN+ 


@6FC11FD RETURN from d_max 
80000061) E 
00194E68 
00192848 
BS289F3E| >#( 
86000088 
26689088 
7EFDEGaGG 
aa41FF18|| gogogaga 
aa41FF1C|| aaaaaaaan 
aa4iFF2a|| 0041FFOS 
GO41FF24 43260308 


Fig. 1.68: OllyDbg : FCOMP a été exécutée 


Nous voyons l'état des flags de condition du FPU : tous a zéro. La valeur dépilée est 
vue ici comme ST(7), la raison a été décrite ici: 1.25.5 on page 293. 
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FNSTSW a été exécutée: 


PUSH EBP 

MOU EBP,ESP 

FLD GWORD PTR SS:IhRG.31 

FCOMP QUORD PTR SS: CARS. 11 s 

00000008 

C FéC4 a5 TEST RH,85 BB41FEDC 

GOFCIBDE AD JPE SHORT 99FC1815 BO41FEDC 

BOFCIB18 FLO QWORD PTR SS: LARG. 1] 66000601 

3 JMP SHORT 69FC1B1S BOF 

FLD QWORD PTR SS: LARG. 31 pl 
BLFFFFFFFF) 

t B(FFFFFFFF) 
BLFFFFFFFF) 

it BLFFFFFFFF) 
TEFDDBBBLFFF) 

it BLFFFFFFFF) 


OU ERP ESP LastErr 90000000 ERROR SUCCESS 
SUB ESP,8 00000206 (NO,NB,NE, A, NS, PE, GE, G) 
FLD GUORD PTR DS: [OFC20E9] arotu Ge 

FSTP_QUORD PTR SS: [LOCAL. 21 empts 

SUB ESP, 8 ss 
FLD GWORD PTR DS: [OFC20D8] HE 
FSTP QUORD PTR SS: LOCAL. 4] pio 


mom om om +... n dr 


CALL aarciaaa 
ADD ESP,8 


FST 0099 
FCW G2?F 
Last cmnd 


RETURN from d mas 


5| 
a 


e 


; 0041FEES 
Bra EME [aaatFEEC 
0041FEFO 

9041FEF4 38 
aa41FEFS| b aarCi11FD RETURN from d mas 

41FEFC| f 00000981 | 6 

41FF00 94E68 
41FF04 
0041FFOS 
904 1FFOC 
G04 1FF1G 
0041FF14 
9041FF1S 
904 1FF1C 
904 1FF20 
DO41IFF24 


Gocconm 


Qoooo 
0000000000 
20 2G 


Fig. 1.69: OllyDbg : FNSTSW a été exécutée 


Nous voyons que le registre AX contient des zéro: en effet, tous les flags de condition 
sont à zéro. (OllyDbg désassemble l'instruction FNSTSW comme FSTSW—elles sont 
synonymes). 
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TEST a été exécutée: 


CPU - main thread, module d_max 


PUSH EBP mE 
FLD QUORD PTR SS: LARG, 31 Jr 

FCOMP QUORD PTR SS: LARG. 11 HSUCR180. — in itenv 
FSTSU AX 


TEST AH, 05 
JPE SHORT GGFC1915 
FLD QUORD PTR SS:LRRG.11 
JMP SHORT GBOFCIO1S 
FLD QUORD PTR SS:LhRG.31 


BBFC 
AAFC 


tsm mmm nn | 


BØFC100E OFC1BA 
ES 902 > OUFFFFFFFF) 


: TEFDDBBatFFF) 
BCFFFFFFFF) 


PUSH EBP oR SUCCESS 
MOU EBP, ESP ERROR_SUCCESS 
SUB ESP.8 ,E, BE, NS, PE, GE, LE) 
FLO GUORD PTR DS: [OFC20E0] 
FSTP QUORD PTR SS: CLOCAL. 21 
SUB ESP,8 

FLO GUORD PTR OS: COFC2008] 
FSTP QUORD PTR SS: LOCAL. 41 
CALL _BBFC1000 

ADD ESP 


On 


Jump is taken 
Dest=d_max.B0FC1815 


8 Ëi. 
Hi+ hh 


RETURN from d mas 


Fig. 1.70: OllyDbg : TEST a été exécutée 


Le flag PF est mis à 1. 


En effet: le nombre de bit mis à O est O et 0 est un nombre pair. olly désassemble 
l'instruction JP comme JPE*!5—elles sont synonymes. Et elle va maintenant se dé- 
clencher. 


115]ump Parity Even (instruction x86) 
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JPE déclenchée, FLD charge la valeur de b (3.4) dans ST(0) : 


CPU - main thread, module d max 


BBFCigoel rs SS PUSH EBP isters (FP 
DOFC 1 082 FLO GORD PTR SS: CARS. 31 À 6494714 
C1903 : i o 
BBFC 1806 FCOMP QUORD PTR SS:CARG. 1] dou | SUCRIED. — In iteny 
DBFCIOB9 FSTSW AX X 66090000 
aarciaaog TEST AH, 05 BO41FEEO 
BØFC100E 7A 05 JPE SHORT BBFC1B15 BOAIFEF4 
FLO GWORD PTR 55: LARG. 1] 00000001 
JMP SHORT ØØFC1018 GGFC3388 d_max. BBFC3388 


FLO QUORD PTR SS:LRRG.31 
POP EBP GGFC1919 d_max.DOFC1019 


INT3 1 BB2B 32bit G(FFFFFFFF) 
INTS S 0023 32bit B(FFFFFFFF) 
INTS SS 0028 32bit OLFFFFFFFF) 
@GFC1G1D INT3 0028 32bit B(FFFFFFFF) 
BBFCIBIE INTS 9053 S2bit EFDDGGO(FFF) 
DOFCIOLE INTS ep 0028 32bit OLFFFFFFFF) 
aarcia2n d MEX 
MDU EBP,ESP 0000088 ERROR SUCCESS 


aarcia2i 

aarciaes 83EC 08 SUB ESP,8 (NO, NB, E, BE, NS, PE, GE, LE) 

aarcia26 DDOS ESG20FCO! FLO QUORD PTR DS: [OFC20E0] 
DD1C24 FSTP_QUORD PTR SS:CLOCAL.2] 


aarciao2ac 
Gerciosr||- 83EC es SUB ESP,8 ST crore 
DDOS FLD QUORD PTR DS: COFC2008] ener 
FSTP QUORD PTR SS:LLOCRL.41 : 


aarcias2 
ES COFFFFFF | CALL gaFCiaaa e 
8304 a8 


E 
FARA empty 
a8 ADD ESP,8 = 6 empty 


Top of stack LOB4iFEEOT-d max empty T 
3800 o 1 aun 

Cu B27F c 11 
Last cmnd 2 C1815 


CITANTET  — — —— — — | ner = 2 EEE 

BBFCSBOO el 66 J z fo zr DOS IEEER 
BOFC3810 : 

DE Cane DO41FEEC 

: | ee Nas ti 94 1FEFG 

Q041FEF4 

94 1FEFS 

94 1FEFC 

904 1FF0 

904 1FFO4 

D041FFOS 

94 1FFOC 

QO41FF16 

804 1FF14 

BG41FF18 

B84 IFFIC 

DO41FF20 

004 1FF24 


... m m m n n n dr 


aarcia4a 


Pointer to next Sly 


Fig. 1.71: OllyDbg : la seconde instruction FLD a été exécutée 


La fonction a fini son travail. 
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Second exemple sous OllyDbg : a=5.6 et b=-4 


Chargeons l'exemple dans OllyDbg : 


CPU - main thread, module d max 


HOO EBP, ESP 
n TE] 
FLO ETES ER SENTE PEER 6E445617 MSUCR199.6E445617 


FCOMP QUORD PTR SS: LARG. 11 
ESTSU AX RS 


TEST AH, oS oe 
JPE SHORT BOFC1D15 

FLO QUORD PTR SS: LARG. 11 e941FEDC 
JMP SHORT BOFCIDIS 

FLO QUORD PTR SS: LARG. 31 L 
POP EBP > BBFC1086 d. FC1906 


RETN FFFFFFFF) 
IN FFFFFFFF) 
IN FFFFFFFF) 
H Bt FFFFFFFF) 
IN TEFDDaaa( FFF) 
IN GCFFFFFFFF) 
PUSH_EBP " 
MOU EBP,ESP LastErs 
SUB ESP.S 000080206 í 
FLD QUORD PTR DS: COFC20E0] 

FSTP QUORD PTR SS:LLOCRL.21 
SUB ESP,8 


FLD GWORD PTR DS: [OFC20D8] 
FSTP QWORD PTR SS:CLOCAL.4] 
CALL aarciaon 


)D (rv D TO 
Doo 


© 


c 


41FEDC BEES CETT 
Ra RETURN from d_max 


25 A 86) 25 
FF FF FF FF FF FF 
FE FF FF FF|91 H eti. 


(+ hN 


RETURN from d mas 


Fig. 1.72: OllyDbg : premier FLD exécutée 


Arguments de la fonction courante: a — 5.6 et b — -4. b (-4) est déjà chargé dans ST(0). 
FCOMP va s'exécuter maintenant. OllyDbg montre le second argument de FCOMP, qui 
est sur la pile juste maintenant. 
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FCOMP a été exécutée: 


CPU - main thread, module d_max 


EE PUSH EEP cp = = 
i En EEEE 

DD45 18 FLD QWORD PTR SS:IRRG.31 617 

DCSD 68 |FCONP QUORD PTR SS: LARG, 11 | PROS 


96000080 


TEST RH, as 
B041FEDC 
JPE SHORT Barciai5 aa841FEDC 


FLD GWORD PTR FE pee 11 GI 00808881 


JMP SHORT GGFC1 C328 : . 
FLD QUORD PTR 20r ei GGFC3388 d_max.GGFC3388 
GGFC16G9 d_max.GGFC1989 


ES 32bit B(FFFFFFFF) 
CS 9823 32bit B(FFFFFFFF) 
GS GaSe Sebit BLFFFFFFFF) 
S it 
gor C1910 FS 0053 32bit 7EFDDOGO(FFF) 
BFC GS 02B 32bit B(FFFFFFFF) 


m 
C182 A 
MOU EBP, ESP LastErr 09090999 ERROR SUCCESS 
SUB ESP,8 09008206 (NO, NB, NE, A, NS, PE, GE, G) 
FLO QUORD PTR DS: CGFC20E0] 


BaFC1821 
FSTP_QUORD PTR SS: LOCAL.21 kia. 
SUB ESP,8 mute 
5 DS20FCOl FLD GWORD PTR DS: [OFC20D8] S empty 
DD1C24 FSTP QWORD PTR SS: LOCAL. 4] STA emot 
ES COFFFFFF CALL G@FCiega tn 
8304 96 D ESP pit 
FST=0I00 (Cazo Coco Cico COSI ES- empty 


PU 
AX=0009 0100 à à 
L1 
FC1 


"E PIN 
ick 


< 


yv. 


wo m om om om n n] n] dr 


Goococcoocco 


Feu G27F 


0 
í 
Last cmnd 0023: G0FC 1006 cnn. BBFC10D6 


QOFC106E 
66666666 

^ cna 

H+ hNy E ó| | cateaeoa 
004 1FF38 

BOFCIIFD 

00000001 

BB194E68 

00192548 

o41FFOS|| es280F3E 

a041FFOC|| aaaaaaan 

0041FF10|| aanaeoon 

0041FF14|| vEFDEaaa 

0041FF18|| oooasano 

0041FF1C|| aaaaaaon 

BB41FF20|| 041FF0S 

Q841FF24 | 43260308 


Fig. 1.73: OllyDbg : FCOMP exécutée 


Nous voyons l'état des flags de condition du FPU : tous à zéro sauf CO. 
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FNSTSW a été exécutée: 


CPU - main thread, mod 


PUSH_EBP 
FLO GUORD PTR SS: LARG. 31 

FCOMP QUORD PTR SS:CARG-11 Seca ee 
FSTSW_AX | 


9000088 


FéC4 05 — — os — 
PCIE ES JP T Bodipeor 


| eee e Me Coe own I 
al 3 Sete : : 

GGFC1815 FLD QWORD PTR SS: [ARG.3] GGFC3388 d_max.@GFC3388 
GBFC1818 SD 69FC199B d_max.G@GFC1G0B 


ES 32bit B(FFFFFFFF) 
CS 9823 32bit B(FFFFFFFF) 
GS ABB Sebit BLFFFFFFFF) 
S it 
gor C1910 FS 0053 32bit 7EFDDOGO(FFF) 
BFC GS B82B 32bit B(FFFFFFFF) 


QGFCIGIF 
al FU BR ESP LastErr 99900000 ERROR SUCCESS 
g SUB ESP, 8 96000206 (NO, NB, NE, A, NS, PE, GE, G) 
FLO _QUORD PTR DS: [OFC29E0] empty 
FSTP QUORD PTR SS:LLOCRL.21 enpty 
SUB ESP, 8 


FLO GWORD PTR DS: [OFC2008] S empty 
FSTP QWORD PTR SS:LLOCRL.41 | 


CALL aarciaaa enpty 


empty 
ADO ESP, 8 saute 


empty —4.0000000008000880800 üa 
0100 LE 
1:1 
100 


wor m om om om m n] n dr 


DODODDDO 


FS 
FCU @27F Prec NEAR,S3 Mask 
Last cmnd @@23: BaFciaae dhan: BOFC1006 


HE 

.« | S041FEES|| doieccee 

Ha RNG 0041FEEC|| 00000000 
aa41FEFG | Cat aeaoa 

aa41FEF4 | üa41FF38 

aa41FEF8 LGGFCIIFD 

@G41FEFC| r 000001 

aa41FFa8 | aa194E68 

aa41FFe4 | 00132848 

0041FFOS|| BS280F3E 

aa41FFeC | aaaaaaan 

aa41FF18 || 000000 

aa41FF14!| 7EFDEGOD 

aa41FF18 || 00000000 

aa41FF1C | 60000000 

aa41FF28 | aa41FFaS 

0041FF24|| 43260308 


Fig. 1.74: OllyDbg : FNSTSW exécutée 


Nous voyons que le registre AX contient 0x100 : le flag CO est au 8iéme bit. 


TEST a été exécutée: 


CPU - main thread, module d_max 


HOU EEP, ESP i rg (FF 
z ER 00000100 
C1003 FLD QWORD PTR SS:CARG.321 FAE 
BOFCIBA6 ECOMP QUORD PTR SS: CARS. 11 ca EVERI REAPSS TT 


aarciaa9 Ea FST 
96000088 
DOFC100B TEST AH, 05 
FA 85 — LUPE SHORT ; aa41FEDC 


aarciaaE A d = IPE T GGFCIBIS — |). Take @041FEDC 

o SEE E TI — 

ØFC1013 rm : e^ 
BeFCiBi5||» $ FLO QWORD PTR SS:LRRG.31 GOFCS388 d_max.00FC3388 
BOFCIB18 SD @OFC1GGE d max.BBFCiODE 


@GFC1G19 oe a 
OOFCIOLA S Bü2B 32bit G(FFFFFFFF) 
AFE TaD ; 8623 32bit B(FFFFFFFF) 
BaFC1B1C 3 BB2B S2bit BLFFFFFFFF) 
@GFC1G1D üü2B 32bit B(FFFFFFFF) | 
BBFCIB1E S 6853 32bit rEFDDBBBLFFF) 
BFC 002B 32bit B(FFFFFFFF) 


@GFC1G1F 
LastErr 60000006 ERROR SUCCESS 


BOFC1G20 
BOFC1i021 

00098202 (NO,NE,NE,A,NS,PO,GE, G) 
FSTP_QUORD PTR SS:LLOCRL.21 Santa 
SUB ESP,8 empty 
FLO QWORD PTR DS:LGFC20D81 empty 
FSTP QUORD PTR SS: LOCAL. 4] BTA anny 
CALL BOFCIOB0 STS empty 
0 a e ADD ESP, 8 en ST6 empty Ø. 
TET ST? empty -à.000000002008600000 
Dezt-d man OG C1015 FST 8188 Cond 8 8 à 1 


row m xcd NEAR, 53 


USH EBP 
MOU EBP,ESP 
SUB ESP,8 
FLD GWORD PTR DS:LOFC2GEOG1 


4 
meer 0000 


MN m [O 


5 


SODA 


GO41FEEG DOFCIDEE 
GO41FEE4| p 66666666| ff 
GG41FEES|| 40166666 
aa41FEEC|| aaaaaaaa 
Caiaaaoaa 
0041FF38 
BaFCii1FD 
99000061) 6 
00194E68 
00192848 
BS288FSE 
20888088 
96080688 
7EFDEGSS 
aaaaaaoaa 
20888088 
0041FFOS 
43269308 


Fig. 1.75: OllyDbg : TEST exécutée 


Le flag PF est mis à zéro. En effet: 


le nombre de bit mis a 1 dans 0x100 est 1, et 1 est un nombre impair. JPE est sautée 
maintenant. 
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JPE n'a pas été déclenchée, donc FLD charge la valeur de a (5.6) dans ST(0) : 


CPU - main thread, module d_max 


PUSH_EBP 

MOU EBP,ESP 

FLD QWORD PTR SS:LRRG.31 
FCOMP GWORD PTR SS: [ARG. 11 
FSTSU AX 

TEST _AH, 05 

JPE SHORT 69FC1615 

FLD QUORD PTR SS:LRRG.11 
JMP SHORT GarFCiais 

FLD GWORD PTR SS:LRRG.31 


GOFC1613 d. 
ES à O(FFFFFFFE) 
GUFFFFFFFF) 


> B(FFFFFFFF) 
@(FFFFFFFF) 


: 7EFDDGGG( FFF) 
Pu : BCFFFFFFFF) 


PUSH EBP or a ROR SUCCESS 
MOU EBP,ESP La GG ERROR SUCCESS 
SUB ESP,8 

FLD QWORD PTR DS: [OFC20E6] 
FSTP_QWORD PTR SS:CLOCAL.2] 
SUB ESP,8 

FLO QWORD PTR DS: [OFC20D8] 
FSTP QWORD PTR SS: LOCAL. 4] 
CALL aarciaeaa 

ADD ESP,8 


nn 


Fig. 1.76: OllyDbg : second FLD exécutée 


La fonction a fini son travail. 


MSVC 2010 avec optimisation 


Listing 1.214 : MSVC 2010 avec optimisation 


_a$ = 8 ; size = 8 
_b$ = 16 ; size = 8 
_d_ max PROC 
fld QWORD PTR b$[esp-4] 
fld QWORD PTR _a$[esp-4] 


; état courant de la pile: ST(0) = a, ST(1) = b 


fcom ST(1) ; comparer _a et ST(1) = (_b) 
fnstsw ax 

test ah, 65 ; 00000041H 

jne SHORT $LN5@d_max 
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; copier ST(0) dans ST(1) et dépiler le registre, 
; laisser ( a) au sommet 
fstp ST(1) 


; état courant de la pile: ST(0) = a 


ret 0 
$LN5Gd max: 
; copier ST(0) dans ST(0) et dépiler le registre, 
; laisser ( b) au sommet 


fstp ST(0) 
; état courant de la pile: ST(0) = b 
ret 0 


_d max ENDP 


FCOM différe de FCOMP dans le sens oü il compare seulement les deux valeurs, et ne 
change pas la pile du FPU. Contrairement à l'exemple précédent, ici les opérandes 
sont dans l'ordre inverse, c'est pourquoi le résultat de la comparaison dans C3/C2/C0 
est différent. 


* Sia» bdans notre exemple, alors les bits C3/C2/C0 sont mis comme suit: 0, O, O. 
* Si b» a, alors les bits sont: O, O, 1. 
* Sia — b, alors les bits sont: 1, O, O. 


L'instruction test ah, 65 laisse seulement deux bits —C3 et C0. Les deux seront à 
zéro si a > b : dans ce cas le saut JNE ne sera pas effectué. Puis FSTP ST(1) suit — 
cette instruction copie la valeur de ST(0) dans l'opérande et supprime une valeur 
de la pile du FPU. En d'autres mots, l'instruction copie ST(0) (où la valeur de a se 
trouve) dans ST(1). Aprés cela, deux copies de a sontsur le sommet de la pile. Puis, 
une valeur est supprimée. Aprés cela, ST(0) contient a et la fonction se termine. 


Le saut conditionnel JNE est effectué dans deux cas: si b > a ou a = b. ST(0) est 
copié dans ST(0), c'est comme une opération sans effet (NOP), puis une valeur est 
supprimée de la pile et le sommet de la pile (ST(0)) contient la valeur qui était 
avant dans ST(1) (qui est b). Puis la fonction se termine. La raison pour laquelle 
cette instruction est utilisée ici est sans doute que le FPU n'a pas d'autre instruction 
pour prendre une valeur sur la pile et la supprimer. 
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Premier exemple sous OllyDbg : a=1.2 et b=3.4 


Les deux instructio 


DD4424 GC 
DD4424 84 
D801 


83EC 18 
DDSC24 a8 
DDOS 


DD1C24 
ES CAFFFFFF 
8835 

DDSC24 88 


$T(1)=3.39999999999999991 16) 
ST=1. 1999999999999999568 


ns FLD ont été exécutées: 


FLD QWORD PTR SS: CARG.3] 
FLD QWORD PTR SS: CARG. 1] 
FCOM ST(1) 


FSTSW AX 
TEST AH, 41 
JNZ SHORT 00A91014 
FSTP ST(1) 
RETN 

FSTP ST 
RETN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 


INT3 
FLD QWORD PTR DS: [BA920E0] 
PUSH ESI 


SUB ESP, 10 

FSTP QWORD PTR SS: [LOCAL.2] 

FLD QWORD PTR DS: [0A920081] 

FSTP QWORD PTR SS: [LOCAL. 4] 

CALL _690A91000 

MOY ESI, DWORD PTR DS:[<&MSUCR100. printf 
FSTP_QWORD PTR SS:CLOCAL.2] 


ODANNDTO 


SOSOOOOS D AHD 


gi 
aan 


ES 


91008 a 


gaz BLFFFFFFFF) 

: B(FFFFFFFF) 

: B(FFFFFFFF) 

; B(FFFFFFFF) 

t ?EFODGGBLFFF) 

t B(FFFFFFFF) 
Err 00 ERROR SUCCESS 
(NO, NB, NE, A, NS, PO, GE, G) 


SPUOZD 
64466 
11111 

00A91004 La 


RETURN from d_max 
ASCII "pNX" 


to next Sl. 


Fig. 1.77: OllyDbg : les deux FLD exécutées 


FCOM exécutée: OllyDbg montre le contenu de ST(0) et ST(1) par commodité. 
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FCOM a été exécutée: 


CPU - main thread, module d_max 


UUnSIOUU ps 004424 GC FLO GWORD PTR SS: CAR Res j 

Gensioo4||- DD4424 64 | FLD QUORD PTR SS: CAR ELEC 

40091008 Econ STEL) - 66394714 ASCII "H(x" 
i 


6802080 


A9 181 FéC4 4 TEST AH, 41 
aQAS100F JMe SHORT 90991014 rentrer 


88491811 FSTP ST(1) G921FCB8 


26491813 RE 99000061 


86491814 ST 
69491816 88893388 d_max. 08493388 


69491917 BOA919GA d_max.GGA91GGA 


0091018 : 
32bit B(FFFFFFFF) 
SUR 1B1A 32bit B(FFFFFFFF) 
OBAS101B 32bit G(FFFFFFFF) 
GGAS1G1C 32bit B(FFFFFFFF) 
0691010 32bit 7EFDDBOBLFFF) 
Ban9181E 32bit B(FFFFFFFF) 
GGA91G1F CC INT3 
0031020 noc FLD QWORD PTR DS: LOM920E0] LastErr 00000000 ERROR SUCCESS 
Banoia26 PUSH LES 1, 00000202 (NO,NB,NE,R, NS, PO, GE, G) 
Banoia27 SUB E 
aanoioan FSTP EMT PTR SS: [LOCAL.2] valid 1.1999999999999999560 
OBAS1D2E FLD QWORD PTR DS:L8Rn928D31 eM LO Br 3.3999999999999999116 
90891934 FSTP QUORD SS: CLOCAL. 41 empty 
MOU ESI, DWORD PTR DS: (<&MSUCR1@@. printf pl 
P_QWORD PTR SS: [LOCAL.2] See empty 


empty 


3100 
G27F 


.... +... n dr 


DOZ1FC6OD 
aa2iFCe4 
aa2iFCes 
@G21FC6C 
8621FC7G 
@B21FC74 
GG21FC78 
@G21FC7C 
9621FC86 
GG21FC84 
8621FC88 
@621FC8C 
aae2ircoa 
aa2iFC94 
aaeiFCco8 
aa2iFC9C 
BOZ1FCAD 
BOZ21FCA4 
9921FCA8 


Fig. 1.78: OllyDbg : FCOM a été exécutée 


C0 est mis, tous les autres flags de condition sont à zéro. 
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FNSTSW a été exécutée, AX=0x3100: 


CPU - main thread, module d_max 


Gonsiaoa|rs DD4d24 OC |FLO QUORD PTR SS:[RRG.3] 
00091004] - DD4424 84 | FLO QUORD PTR SS:CARG. 1] 
eensiess||-  DeDi FCOM ST(1) 
90891008 DFEG FSTSW AX 

3100F 3 


888918011 
68491913 
66491814 
66491916 
88491917 
69491918 
68491913 
8849319814 
6BA91G1B 
68491810 
68491910 
GGA91G1E 
@BA91G1F 
62491928 
G6A91926 
26491927 
88491924 
G9A9102E 
86491934 
26491937 
88491930 


cc INT3 
DDOS EG29A9û FLO QUORD PTR DS: [OA920E0] 
56 PUSH_ESI 


83EC 18 SUB ESP,18 

DDSC24 a8 FSTP QWORD PTR SS: [LOCAL.2] 

DDOS 0829498 FLO GWORD PTR DS: LGR928D81 

DD1C24 FSTP QWORD PTR SS:CLOCAL.4] 

ES C4FFFFFF | CALL 99491988 

8B35 MOU ESI, DWORD PTR DS: (<&MSUCR160. printf 
ODSC24 48 FSTP QWORD PTR SS:CLOCAL.2] 


5 


SCII “Administrator” 
i ac EL Ts "HEX 
ogogo 
20828088 
BO21FC60 
BOZ21FCBS 
96000081 
80893388 d_max.GGA93388 


@GA91G6C d_max.GGA91G8C 


ES S2bit G(FFFFFFFF) 
32bit G(FFFFFFFF) 
S2bit G(FFFFFFFF) 
S2bit B(FFFFFFFF) 
S2bit vEFDDaGatFFF) 
32bit G(FFFFFFFF) 


LastErr 00000008 ERROR SUCCESS 
00000202 (NO,NB,NE,R,NS,PO, GE, G) 


valid 1.1999999999999999569 
valid 3.3999999999999999110 
empty B. 


9.8 
0.0 
a.a 
0.0 
0.0 
0.0 


321 PUO 
6686 "eau 
111 
A91008 


con 
aa2iFCe4 
aaeiFCes 
BOZ21FC6C 
aaeiFCra 
aa2iFC?4 
aaeiFC?S 
BO21FC7C 
aaeiFCsa 
aa2irCco4 
aa2eiFCSss 
BO21FCSC 
aaeiFCoan 
aa2iFCo4 
aaeiFCoS 
aa2iFCSC 
BOZ1FCAD 


Fig. 1.79: OllyDbg : FNSTSW est exécutée 


[4 
6 
1 
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TEST est exécutée: 


DD4424 GC 
8GA91904 DD4424 84 


68491988 


FLO QWORD PTR SS: CARG.3] 
FLO QWORD PTR SS:LRRG.11 
FCOM ST(1) 


[ESTP STC) 
RETN 


68491917 
88491815 
69491913 
88491814 
69491918 
68491810 
86491910 
BOA91D1E 
GBA91G1F 
BOA91020 
29491826 
68491827 
aanoia2n 
aanoia2E 
69491934 


$ 


Jump is taken 
Dest=d_max.60A91014 


ST 


INTS 
FLO QWORD PTR DS: [OA920E0] 
PUSH_ESI 


SUB ESP, 10 

FSTP QWORD PTR SS: [LOCAL. 2] 
FLO QWORD PTR DS: [6A92008] 
FSTP QWORD PTR SS: [LOCAL. 4] 


91000 
MOU E ORD PTR DOLEO. printf 
FSTP QUÓRO PTR SS: [LOCAL.2 


00583100 ASCII Administrator” 

6E494714 ASCII "HIX 

66689069 

66666600 

Gg21FC60 

aa2iFCBS 

69069881 

88893388 d_max.08A493388 

BOA91B0F d_max.GGA910GF 
32bit G(FFFFFFFF) 
32bit G(FFFFFFFF) 
32bit GCFFFFFFFF) 
32bit GCFFFFFFFF) 
32bit 7EFODGGG(FFF) 
32bit GCFFFFFFFF) 


LastErr 400000068 ERROR SUCCESS 
99086262 (NO,NB,NE,A,NS,PO,GE,G) 


. 1999999999999999568 
aaa ela iO 


valid 
valid 
empty 


32180 PUO 
Cond 8 à Ø 1 H o Fa 
0023: 00491008 d_man. 00A91908 


Ba21iFCé4 
@G21FC68 
@621FC6C 
aaeiFC?ao 
aa2iFC?4 
aaeiFC?8 
aae2iFC?C 
aaeiFcean 
aa2iFC84 
aa2iFCes 
9621FC8C 
8621FC96 
@G21FC94 
8621FC93 
@G21FC9C 
@621FCAG 
@621FCA4 
SAS LEURS 


Fig. 1.80: OllyDbg : TEST est exécutée 


ZF=0, le saut conditionnel va être déclenché maintenant. 
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FSTP ST (ou FSTP ST(0)) a été exécuté —1.2 a été dépilé, et 3.4 laissé au sommet 
de la pile: 


main thread, module d_max 


DD4424 GC FLD QWORD PTR SS: [ARG. 3] 
DD4424 84 FLO QUORD PTR SS: ARG. 11 
FCOM ST(1) 
DO0A910GA FSTSW AX 
a aac TEST RH,41 

a 75 63 JNZ SHORT 88891814 
Eam sT(1) 


BLFFFFFFFF) 
BLFFFFFFFF) 

it B(FFFFFFFF) 
BLFFFFFFFF) 
7EFDDGGG( FFF) 
BLFFFFFFFF) 


89491826 
68491827 
88491824 
GGAS182E 


2 
cc INTS 
DDOS EG208901 FLD QUORD PTR DS: [BA920E0] 
56 PUSH_ESI 
SSEC 18 SUB ESP, 10 
DDSC24 08 FSTP QWORD PTR SS: [LOCAL.21 - 
DDOS 0529498 FLO WORD PTR DS: 932808] T2 empty 
DD1C24 FSTP QWORD PTR SS: [LOCAL.41 empty à 
dada CALL aan9ial 


MOU ESI, DWORD PTR DS: L4&MSUCRIBB. printf ere 


mom om m om n . dr 


Baeon2ot 
DDSC24 68 FSTP_QUORD PTR SS:LLOCRL.21 


Top of stack [BB21FC6067=d_max. BBA91B3C S S 
SPUOZD 


000068 
11111 
an. D0A91014 hd 


90000061) © 

@GAS11ED| 344 | RETURN from d max 
90060001) E 

a SCII ”pNx” 


: a 
@G21FCA4 
8G21FCAS ei Ce | Pointer to next Sly. 


Fig. 1.81: OllyDbg : FSTP est exécutée 


Nous voyons que l'instruction FSTP ST 


fonctionne comme dépiler une valeur de la pile du FPU. 
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Second exemple sous OllyDbg : a=5.6 et b=-4 


Les deux FLD sont exécutées: 


CPU - main thread, module d_max 


DD4424 GC FLO QUORD PTR SS: CARG.3] 
DD4424 64 FLO QWORD PTR SS: [ARG.1] 


a * DSDi FCOM ST(1) 
BBAS10BA FSTSW AX 
96A9196C TEST AH, 41 
JNZ SHORT 00091014 
FSTP ST(1) 


? MSUCR1GG.6E 445617 


ST 6E445584 MSUCR1BB. printf 
80893388 d_max. 00A93338 


80891808 d_max.00A91008 


ES 0B2B 32bit G(FFFFFFFF] 
(S$ 0023 32bit G(FFFFFFFF) 
S 002B 32bit B(FFFFFFFF) 
962B it GCFFFFFFFF) 

5 GBSS 32bit PEFODGGG( FFF) 
B02B 32bit BIFFFFFFFF) 


GC INTS IS CR RUN 
DOSS EO20890l FLD QUORD PTR DS: [OA920E8] beasties 00009008, ERROR SUCCESS 
56 PUSH ESI 00008246_(NO, NB, E, BE, NS, PE, GE, LE) 
83EC 10 SUB ESP, 


18 " 
E 
Doscz4 08 — |FSTP QUÓRD PTR SS: [LOCAL.2] Le 
DDGS DS20890l FLO QUORD PTR DS:LORS28D81 e 
D1C24 FSTP QUORD PTR SS:LLOCRL.41 KR 
ES C4FFFFFF [CALL BBh91000 eot) d: 
MOU ESI,DUORD PTR DS: [<£MSUCRIDO. printf n 7 
à 
à 


mom om +... n n dr 


8B35 gazoasa pt. 
88091842 DD5c24 ü8 ^ |FSTP QUÓRO PTR SS:LLOCRL.21 a Pd 
STC1J 2-4. GOGDODOOODOCOUUOUOO C Enpey es 210 
ST=5.5999999999999996440 3100 Cond 8 B B 1 
Cu B27F Prec NEAR,53 
Last cmnd 686; 


- 0 TT 
8 :971- B 7 
NEU Ca1880000 
HIX hNX a GG0000 1 
RETURN from d_max 


x ASCII "pNX" 
aa2iFCS4 
8621FC83 
Eu E 


68493808 a 
aanosaEa 
aanssara OBZ1FCAD 


BOR E Ba21FCR4 
Ed 06 00 60 00 00 0 Ga 60 GG 06/00 OB OD 2 1FCAS 982 1FCFA|: t [Pointer to next Sly 


Fig. 1.82: OllyDbg : les deux FLD sont exécutée 


FCOM est sur le point de s'exécuter. 
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FCOM a été exécutée: 


66491606 
62491484 
6491908 


68491811 
86491813 
66491214 
88491816 
68491917 
88491815 
68491913 
88491814 
63491918 
68491810 
86491910 
GBA91G1E 
GBA91B1F 
BOA91020 
28491826 
68491827 
BBA9102A 
BOA9102E 
69491934 


main thread, module d_max 


E 


$ 


DD4424 BC 
DD4424 a4 


FLO QWORD PTR SS:LRRG.31 
FLO QWORD PTR SS:LRRG.11 


FCOM Tt) 
| EUR 


TEST AH, 41 
JNZ SHORT 88891814 
m ST(1) 


ST 


INTS 
FLO QWORD PTR DS: [OA920E0] 
PUSH_ESI 


SUB ESP, 10 

FSTP QWORD PTR SS: [LOCAL. 2] 
FLO QWORD PTR DS: [6A92008] 
FSTP mE bun SS: [LOCAL. 4] 


MOU ESI, SONORO PTR O printf 
P QUÓRO PTR SS: [LOCAL.2 


EE] 

6E445617 MSUCRIBO.6E445617 
BaaaFDE?S 

66686606 

BO21FC60 

aaeiFCBS 

6E445584 MSUCR19B. printf 
00A93388 d_max.G6A93383 


88R9188R d_max. 00A9100A 


32bit B(FFFFFFFF) 
32bit B(FFFFFFFF) 
32bit BLFFFFFFFF) 
32bit BLFFFFFFFF) 
32bit 7EFDDOBBLFFF) 
32bit B(FFFFFFFF) 


LastErr 400000008 ERROR SUCCESS 
99006246 (NO,NB,E,BE,NS,PE,GE,LE) 


valid 
valid 
empty 
empty 
empty 
empty 
empty 
empty 


3000 
aevF 
Last cmnd 


Ba21iFCé4 
aa2iFCces8 
aa2iFCec 
BB21FC70 
aa2iFC?4 
aaeiFC?8 
aae2iFC?C 
aa2eiFcean 
aa2iFC84 
aa2iFCes 
9621FC8C 
8621FC96 
@G21FC94 
8621FC93 
@G21FC9C 
@621FCAG 
@621FCA4 
meet EURE 


5.599999999999999644D 
cao 


Fig. 1.83: OllyDbg : FCOM est terminé 


Tous les flags de conditions sont a zéro. 


FNSTSW fait, AX=0x3000: 


CPU - main thread, module d_max 


Seal: Von T 
[EAX 00003008 | 

sonsioos | :  D8D1 OM ST(I EEE 
ac BODFDE?S 

JNZ SHORT 8091014 eireta 
FSTP ST(1) Ba21FCB8 
RETN 6E445584 MSUCR1OB.printf 
88893388 d_max. 00498388 


BOA9100C d_max . BBA91BBC 


ES 32bit G(FFFFFFFF) 
cs S2bit G(FFFFFFFF]) 
ss 32bit G(FFFFFFFF) 
os S2bit ØLFFFFFFFF) 
FS 32bit TEFDDOGB(FFF) 
65 32bit BtFFFFFFFF) 


AD WORD PTR Dei teasseead LastErr 99900000 ERROR SUCCESS 
PUSH ESI 00000246 (NO,NB,E,BE,NS, PE, GE, LE) 
SUB ESP, 19 i 
z . valid 5.5999999999999996449 
ol EE AO P TR SE DLOCRL S21 valid -4.0000000000000000008 
FSTP QWORD PTR SS:LLOCRL.41 empty 8.8 
CALL _66A91008 pt 
MOU ESI, DWORD PTR DS: [<2MSUCR1BB. printf 


E empty 
FSTP QWORD PTR SS:LLOCRL.21 .. empty 


empty 


3000 
G27F 


MSUCR100,6E445617 


0A991020 
0A991026 
00A91027 
6834931824 
@6A9162E 
68491834 
88491837 
8934931830 


mom om om m n n n dr 


0A991042 


Ao ZFA 


. 8 7974-F 
8093830 8 HIX hNX 
aanosa4a 
DOA93050 
aanosa6a 
00A93070 
0A993080 
0A923090 
aanosana 
aanssaBa 
aanssaca 
aanssapa 
aanssaEa 
aanssara 
68493100 
29493118 


Fig. 1.84: OllyDbg : FNSTSW a été exécutée 
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TEST a été exécutée: 


|] CPU - main thread, module d max [ei [aT ES 
) p 


BansiaaB|nrs DD4424 BC FLD GWORD PTR SS: CARG.3] "ai 
BBA91004 DD4424 84 FLD QUORD PTR SS:LRRG.11 ELLE 


her pen? FCOM STC1) 6E445617 MSUCRIDO. 6E445617 
Peed 41 TEST AH, 41 pre Te. 
jn E E | - | 00000000 
Em 3 i GG21FC60 

G2 1FCES 
6445584 MSUCR190. printf 
GGAS3388 d max. 00193388 


GGA91GGF d_max.GGA91G6F 


32bit B(FFFFFFFF) 
32bit G(FFFFFFFF) 
32bit B(FFFFFFFF) 
32bit B(FFFFFFFF) 
32bit 7EFDDGOG( FFF) 
32bit G(FFFFFFFF) 


Gococooococo 
DA Pt Pt pa I Ih ee 
CODD: 00-0 


o 
o 
D 
m 
= 
co 


GGA91G1E 
BBA91B1F 
0A991020 
0A921026 
0A921027 
BOA9102A 


CC INT3 
DOGS EG20n9o!FLD QUORD PTR DS: [OA920E0] ROBGU eee ERRORCSUDCESS 
56 USH ESI 00000246 (NO, NB,E,BE, NS, PE, GE, LE) 
83EC 18 SUB ESP, 19 

DDsc24 28 |FSTP QUÓRD PTR SS: [LOCAL. 21 MORE PRE ÉTÉ RE EE ant 

DOGS DS20n9al FLO QWORD PTR DS:L6Rn928D31 ene 

DD1C24 FSTP QWORD PTR SS:LLOCRL.41 eno 

EB C4FFFFFF | CALL Bonoigaa empty 

MOU ESI,DUORD PTR DS: C<&MSUCRIO0. printf 


8635 Büeonso! 
DDSC24 68 — |FSTP QUORD PTR SS: [LOCAL.2] T pl 


taken A a E 
Dest=d_max . 00A91014 3000 Cond à 6 à à Err 6 
@27F Prec NEAR,S3 Mask 
Last cmnd 0023: 


5 


GG21F CEA 

GS 1FCÉS 

t |éstrcre 
HIX AN aaz1FCr4 
Ba21FCr8 
Ba21FCTC 
Ba21FCSÓ 
Ba21FC84 

GS 1FCES 
Ba21FCBC 
Ba21FC98 
Ba21FC94 
Ba21FC98 
Ba21FC9C 
Ba21FCh8 


Fig. 1.85: OllyDbg : TEST a été exécutée 


ZF=1, le saut ne va pas se produire maintenant. 
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FSTP ST(1) a été exécutée: une valeur de 5.6 est maintenant au sommet de la pile 
du FPU. 


CPU - main thread, module d_max 


$ DD4424 BC FLO QWORD PTR SS: CARG.3] 
* DD4424 84 FLO QUORD PTR SS:LRRG.11 
FCOM ST(1) 

FSTSU AX 


TEST RH,41 

JNZ SHORT 88891814 
FSTP ST(1) 

RETN 


EIP 88091018 d_ma. BAAS 
a 


G(FFFFFFFF) 
BtFFFFFFFF) 
TEFDDaaeatFFF) 
atFFFFFFFF) 


HNND TO 
DOG 


oo 


cc IN 

DDOS EG200901 FLO QUORD PTR DS: [BA920E0] 

56 PUSH_ESI 

SSEC 16 SUB ESP, 10 

DDSC24 63 FSTP QWORD PTR SS: LOCAL. 21 

DDOS FLD QWORD PTR DS: [0A920081] 

DD1C24 FSTP QWORD PTR SS: [LOCAL. 4] 

ES C4FFFFFF | CALL aanoiaaa 

8B35 MOV ESI, DWORD PTR DS: [<8MSUCR1G0. printf 


sr 


Bazagaot 
DDSC24 68 FSTP_QUORD PTR SS:LLOCRL.21 


Top of stack [OB2IFCOUI-d man. DANS 106S 


25 A 
FF FF FF FF FF FF F 
FE FF FF FF| 1 


RETURN from d max 


ASCII "pNx" 


Fig. 1.86: OllyDbg : FSTP a été exécutée 


Nous voyons maintenant que l'instruction FSTP ST(1) fonctionne comme suit: elle 
laisse ce qui était au sommet de la pile, mais met ST(1) à zéro. 


GCC 4.4.1 


Listing 1.215 : GCC 4.4.1 


d max proc near 


b - qword ptr -10h 
a - qword ptr -8 
a first half - dword ptr 8 
a second half = dword ptr OCh 
b first half - dword ptr 10h 
b second half = dword ptr 14h 


push ebp 
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mov ebp, esp 
sub esp, 10h 


; mettre a et b sur la pile locale: 


mov eax, [ebp+a first half] 
mov dword ptr [ebp+a], eax 
mov eax, [ebp+a second half] 
mov dword ptr [ebp+a+4], eax 
mov eax, [ebp+b first half] 
mov dword ptr [ebp+b], eax 
mov eax, [ebp+b second half] 
mov dword ptr [ebp+b+4], eax 


; charger a et b sur la pile du FPU: 


fld [ebp+a] 
fld [ebp+b] 


; état courant de la pile: ST(0) - b; ST(1) - a 
fxch st(1) ; cette instruction échange ST(1) et ST(Q) 
; état courant de la pile: ST(0) - a; ST(1) - b 


fucompp ; comparer a et b et prendre deux valeurs depuis la pile, 
i.e., a et b 
fnstsw ax ; stocker l'état du FPU dans AX 


sahf ; charger l'état des flags SF, ZF, AF, PF, et CF depuis AH 
setnbe al ; mettre 1 dans AL, si CF=0 et ZF=0 
test al, al ; AL==0 ? 
jz short loc 8048453 ; oui 
fld [ebp+a] 
jmp short locret_8048456 
loc 8048453: 
fld [ebp+b] 
locret_8048456: 
leave 
retn 
d_max endp 


FUCOMPP est presque comme FCOM, mais dépile deux valeurs de la pile et traite les 
«non-nombres » différemment. 


Quelques informations à propos des not-a-numbers (non-nombres). 


Le FPU est capable de traiter les valeurs spéciales que sont les not-a-numbers (non- 
nombres) ou NaNs. Ce sont les infinis, les résultat de division par 0, etc. Les non- 
nombres peuvent être «quiet » et «signaling ». ll est possible de continuer à travailler 
avec les «quiet » NaNs, mais si l'on essaye de faire une opération avec un «signaling » 
NaNs, une exception est levée. 
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FCOM léve une exception si un des opérandes est NaN. FUCOM léve une exception 
seulement si un des opérandes est un signaling NaN (SNaN). 


L'instruction suivante est SAHF (Store AH into Flags stocker AH dans les Flags) —est 
une instruction rare dans le code non relatif au FPU. 8 bits de AH sont copiés dans 
les 8-bits bas dans les flags du CPU dans l'ordre suivant: 

7 


6 4 2 0 


SFZF AF| PF CF 


Rappelons que FNSTSW déplace des bits qui nous intéressent (C3/C2/C0) dans AH et 
qu'ils sont aux positions 6, 2, O du registre AH. 


1 0 


C3 C2CICO 


En d'autres mots, la paire d'instructions fnstsw ax / sahf déplace C3/C2/C0 dans 
ZF, PF et CF. 


Maintenant, rappelons les valeurs de C3/C2/C0 sous différentes conditions: 


* Si a est plus grand que b dans notre exemple, alors les C3/C2/C0 sont mis à: 0, 
0, 0. 


* Si a est plus petit que 5, alors les bits sont mis à: O, O, 1. 
e Si a=b, alors: 1, 0, O. 


En d'autres mots, ces états des flags du CPU sont possible aprés les trois instructions 
FUCOMPP/FNSTSW/SAHF : 


* Si a» b, les flags du CPU sont mis à: ZF=0, PF=0, CF=0. 
e Si a <b, alors les flags sont mis a: ZF=0, PF=0, CF=1. 
e Etsi a=b, alors: ZF=1, PF=0, CF=0. 


Suivant les flags du CPU et les conditions, SETNBE met 1 ou 0 dans AL. C'est presque 
la contrepartie de JNBE, avec l'exception que SETcc!!© met 1 ou 0 dans AL, mais Jcc 
effectue un saut ou non. SETNBE met 1 seulement si CF=0 et ZF=0. Si ce n'est pas 
vrai, O est mis dans AL. 


Il y a un seul cas où CF et ZF sont à 0: si a» b. 


Alors 1 est mis dans AL, le JZ subséquent n'est pas pris et la fonction va renvoyer 
. a. Dans tous les autres cas, b est renvoyé. 


GCC 4.4.1 avec optimisation 


Listing 1.216 : GCC 4.4.1 avec optimisation 


public d max 
d max proc near 


116cc est un condition code 
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arg_0 = qword ptr 8 
arg_8 = qword ptr 10h 
push ebp 
mov ebp, esp 
fld [ebp+arg 0] ; a 
fld [ebp+arg_ 8] ; b 
; état de la pile maintenant: ST(0) = b, ST(1) = a 
fxch st(1) 
; état de la pile maintenant: ST(0) = a, ST(1) = b 


fucom st(1) ; comparer a et b 
fnstsw ax 

sahf 

ja short loc 8048448 


; stocker ST(0) dans ST(0) (opération sans effet), 
; dépiler une valeur du sommet de la pile, 
; laisser b au sommet 

fstp st 

jmp short loc 804844A 


loc 8048448: 
; stocker a dans ST(1), dépiler une valeur du sommet de la pile, laisser a 


au sommet 
fstp st(1) 


loc 804844A: 
pop ebp 
retn 

d max endp 


C'est presque le méme, à l'exception que JA est utilisé aprés SAHF. En fait, les ins- 
tructions de sauts conditionnels qui vérifient «plus», «moins » ou «égal» pour les 
comparaisons de nombres non signés (ce sont JA, JAE, JB, JBE, JE/JZ, JNA, JNAE, 
JNB, JNBE, JNE/JNZ) vérifient seulement les flags CF et ZF. 


Rappelons comment les bits C3/C2/C0 sont situés dans le registre AH après l'exé- 
cution de FSTSW/FNSTSW : 


6 2 1 0 


C3 cacico 


Rappelons également, comment les bits de AH sont stockés dans les flags du CPU 
aprés l'exécution de SAHF : 


7 6 4 2 0 


SFZF| AF [PF CF 


Aprés la comparaison, les bits C3 et CO sont copiés dans ZF et CF, donc les sauts 
conditionnels peuvent fonctionner aprés. st déclenché si CF et ZF sont tout les deux 
à Zéro. 
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Ainsi, les instructions de saut conditionnel listées ici peuvent étre utilisées aprés une 
paire d'instructions FNSTSW/SAHF. 


Apparemment, les bits d'état du FPU C3/C2/C0 ont été mis ici intentionnellement, 
pour facilement les relier aux flags du CPU de base sans permutations supplémen- 
taires? 


GCC 4.8.1 avec l'option d'optimisation -03 


De nouvelles instructions FPU ont été ajoutées avec la famille Intel P6117. Ce sont 
FUCOMI (comparer les opérandes et positionner les flags du CPU principal) et FCMOVcc 
(fonctionne comme CMOVcc, mais avec les registres du FPU). 


Apparemment, les mainteneurs de GCC ont décidé de supprimer le support des CPUs 
Intel pré-P6 (premier Pentium, 80486, etc.). 


Et donc, le FPU n'est plus une unité séparée dans la famille Intel P6, ainsi il est 
possible de modifier/vérifier un flag du CPU principal depuis le FPU. 


Voici ce que nous obtenons: 


Listing 1.217 : GCC 4.8.1 avec optimisation 


fld QWORD PTR [esp+4] ; charger "a" 
fld QWORD PTR [esp+12] ; charger "b" 
; STO=b, ST1-a 

fxch st(1) 

; STO-a, ST1=b 


; comparer "a" et "b" 

fucomi st, st(1) 

; copier ST1 ("b" ici) dans STO si a<=b 
; laisser "a" dans STO autrement 
fcmovbe st, st(1) 

; supprimer la valeur dans STI 

fstp st(1) 

ret 


Difficile de deviner pourquoi FXCH (échange les opérandes) est ici. 


Il est possible de s'en débarrasser facilement en échangeant les deux premiéres 
instructions FLD ou en remplacant FCMOVBE (below or equal inférieur ou égal) par 
FCMOVA (above). Il s'agit probablement d'une imprécision du compilateur. 


Donc FUCOMI compare ST(0) (a) et ST(1) (5) et met certains flags dans le CPU prin- 
cipal. FCMOVBE vérifie les flags et copie ST(1) (b ici à ce moment) dans ST(0) (a ici) 
si STO(a) <= ST1(b). Autrement (a > b), a est laissé dans ST(0). 


Le dernier FSTP laisse ST(0) sur le sommet de la pile, supprimant le contenu de 
ST(1). 


Exécutons pas à pas cette fonction dans GDB: 


117À partir du Pentium Pro, Pentium-ll, etc. 


Ui BUNH 
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Listing 1.218 : GCC 4.8.1 avec optimisation and GDB 


dennis@ubuntuvm:~/polygon$ gcc -03 d max.c -o d max -fno-inline 
dennis@ubuntuvm:~/polygon$ gdb d max 
GNU gdb (GDB) 7.6.1-ubuntu 


Reading symbols from /home/dennis/polygon/d max...(no debugging symbols 7 
S found)...done. 

(gdb) b d max 

Breakpoint 1 at 0x80484a0 

(gdb) run 

Starting program: /home/dennis/polygon/d max 


Breakpoint 1, 0x080484a0 in d max () 

(gdb) ni 

0x080484a4 in d max () 

(gdb) disas $eip 

Dump of assembler code for function d max: 


0x080484a0 «40»: fidi 0x4(%esp) 

=> 0x080484a4 <+4>: fldl Oxc(%esp) 
0x080484a8 <+8>: fxch %st(1) 
0x080484aa <+10>: fucomi %st(1),%st 
0x080484ac <+12>: fcmovbe %st(1),%st 
0x080484ae <+14>: fstp %st(1) 
0x080484b0 <+16>: ret 

End of assembler dump. 

(gdb) ni 


0x080484a8 in d max () 
(gdb) info float 
R7: Valid  0x3fff9999999999999800 +1.199999999999999956 
=>R6: Valid 0x4000d999999999999800 +3.399999999999999911 
R5: Empty  0x00000000000000000000 
R4: Empty 3 0x00000000000000000000 
R3: Empty  0x00000000000000000000 
R2: Empty  0x00000000000000000000 
R1: Empty 0x00000000000000000000 
RO: Empty — 0x00000000000000000000 


Status Word: 0x3000 
TOP: 6 
Control Word: 0x037f IM DM ZM OM UM PM 


PC: Extended Precision (64-bits) 
RC: Round to nearest 


Tag Word: OxOfff 
Instruction Pointer: 0x73:0x080484a4 
Operand Pointer: Ox7b:0xbffff118 
Opcode: 0x0000 

(gdb) ni 

0x080484aa in d max () 

(gdb) info float 


R7: Valid  0x4000d999999999999800 +3.399999999999999911 
=>R6: Valid  0x3fff9999999999999800 +1.199999999999999956 

R5: Empty 0x00000000000000000000 

R4: Empty — 0x00000000000000000000 
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R3: Empty  0x00000000000000000000 
R2: Empty | 0x00000000000000000000 
R1: Empty — 0x00000000000000000000 
RO: Empty 0x00000000000000000000 


Status Word: 0x3000 
TOP: 6 
Control Word: 0x037f IM DM ZM OM UM PM 


PC: Extended Precision (64-bits) 
RC: Round to nearest 


Tag Word: OxOfff 
Instruction Pointer: 0x73:0x080484a8 
Operand Pointer: Ox7b:0xbffff118 
Opcode: 0x0000 


(gdb) disas $eip 
Dump of assembler code for function d max: 


0x080484a0 «40»: fldl 0x4(%esp) 
0x080484a4 <+4>: fldl Oxc(%esp) 
0x080484a8 <+8>: fxch %st(1) 

=> 0x080484aa <+10>: fucomi %st(1),%st 
0x080484ac <+12>: fcmovbe %st(1),%st 
0x080484ae <+14>: fstp %st(1) 
0x080484b0 <+16>: ret 

End of assembler dump. 

(gdb) ni 


0x080484ac in d_max () 
(gdb) info registers 


eax 0x1 1 

ecx Oxbffff1c4 - 1073745468 
edx 0x8048340 134513472 
ebx Oxb7fbf000 - 1208225792 
esp Oxbffff10c Oxbffff10c 
ebp Oxbffff128 Oxbffff128 
esi 0x0 0 

edi 0x0 0 

eip 0x80484ac 0x80484ac <d_max+12> 
eflags 0x203 [ CF IF ] 

CS 0x73 115 

ss 0x7b 123 

ds 0x7b 123 

es 0x7b 123 

fs 0x0 0 

gs 0x33 51 

(gdb) ni 


0x080484ae in d_max () 
(gdb) info float 
R7 


: Valid | 0x4000d999999999999800 +3.399999999999999911 
=>R6: Valid | 0x40004d999999999999800 +3.399999999999999911 


R5: Empty — 0x00000000000000000000 
R4: Empty | 0x00000000000000000000 
R3: Empty | 0x00000000000000000000 
R2: Empty | 0x00000000000000000000 
R1: Empty — 0x00000000000000000000 
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RO: Empty — 0x00000000000000000000 


Status Word: 0x3000 
TOP: 6 
Control Word: 0x037f IM DM ZM OM UM PM 


PC: Extended Precision (64-bits) 
RC: Round to nearest 


Tag Word: OxOfff 
Instruction Pointer: 0x73:0x080484ac 
Operand Pointer: Ox7b:0xbffff118 
Opcode: 0x0000 


(gdb) disas $eip 
Dump of assembler code for function d max: 


0x080484a0 «40»: fldl 0x4(%esp) 
0x080484a4 <+4>: fldl Oxc(%esp) 
0x080484a8 <+8>: fxch  %st(1) 
0x080484aa <+10>: fucomi %st(1),%st 
0x080484ac <+12>: fcmovbe %st(1),%st 

=> 0x080484ae <+14>: fstp  *sst(1) 
0x080484b0 «416»: ret 

End of assembler dump. 

(gdb) ni 


0x080484b0 in d max () 
(gdb) info float 
=>R7: Valid 0x4000d999999999999800 +3.399999999999999911 
R6: Empty — 0x4000d999999999999800 
R5: Empty  0x00000000000000000000 
R4: Empty 0x00000000000000000000 
R3: Empty  0x00000000000000000000 
R2: Empty  0x00000000000000000000 
R1: Empty  0x00000000000000000000 
RO: Empty — 0x00000000000000000000 


Status Word: 0x3800 
TOP: 7 
Control Word: 0x037f IM DM ZM OM UM PM 


PC: Extended Precision (64-bits) 
RC: Round to nearest 


Tag Word: Ox3fff 
Instruction Pointer: 0x73:0x080484ae 
Operand Pointer: Ox7b:0xbffff118 
Opcode: 0x0000 

(gdb) quit 


A debugging session is active. 
Inferior 1 [process 30194] will be killed. 


Quit anyway? (y or n) y 
dennis@ubuntuvm:~/polygon$ 


En utilisant «ni», exécutons les deux premières instructions FLD. 


Examinons les registres du FPU (ligne 33). 
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Comme cela a déja été mentionné, l'ensemble des registres FPU est un buffeur cir- 
culaire plutót qu'une pile (1.25.5 on page 293). Et GDB ne montre pas les registres 
STx, mais les registre internes du FPU (Rx). La fléche (à la ligne 35) pointe sur le haut 
courant de la pile. 


Vous pouvez voir le contenu du registre TOP dans le Status Word (ligne 36-37)—c'est 
6 maintenant, donc le haut de la pile pointe maintenant sur le registre interne 6. 


Les valeurs de a et b sont échangées aprés l'exécution de FXCH (ligne 54). 
FUCOMI est exécuté (ilgne 83). Regardons les flags: CF est mis (ligne 95). 
FCMOVBE a copié la valeur de b (voir ligne 104). 


FSTP dépose une valeur au sommet de la pile (ligne 139). La valeur de TOP est 
maintenant 7, donc le sommet de la pile du FPU pointe sur le registre interne 7. 


ARM 
avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Listing 1.219 : avec optimisation Xcode 4.6.3 (LIVM) (Mode ARM) 


VMOV D16, R2, R3 ; b 

VMOV D17, RO, R1; a 

VCMPE. F64 D17, D16 

VMRS APSR_nzcv, FPSCR 

VMOVGT . F64 D16, D17 ; copier "a" dans D16 
VMOV RO, R1, D16 

BX LR 


Un cas très simple. Les valeurs en entrée sont placées dans les registres D17 et D16 
puis comparées en utilisant l'instruction VCMPE. 


Tout comme dans le coprocesseur x86, le coprocesseur ARM a son propre registre 
de flags (FPSCR?18), puisqu'il est nécessaire de stocker des flags spécifique au co- 
processeur. Et tout comme en x86, il n'y a pas d'instruction de saut conditionnel qui 
teste des bits dans le registre de status du coprocesseur. Donc il y a VMRS, qui copie 
4 bits (N, Z, C, V) du mot d'état du coprocesseur dans les bits du registre de status 
général (APSR1?). 


VMOVGT est l'analogue de l'instruction MOVGT pour D-registres, elle s'exécute si un 
opérande est plus grand que l'autre lors de la comparaison (GT—Greater Than). 


Si elle est exécutée, la valeur de a sera écrite dans D16 (ce qui est écrit en ce moment 
dans D17). Sinon, la valeur de b reste dans le registre D16. 


La pénulti&me instruction VMOV prépare la valeur dans la registre D16 afin de la ren- 
voyer dans la paire de registres RO et R1. 


118(ARM) Floating-Point Status and Control Register 
119(ARM) Application Program Status Register 
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avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


Listing 1.220 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


VMOV D16, R2, R3 ; b 
VMOV D17, RO, R1; a 
VCMPE. F64 D17, D16 

VMRS APSR_nzcv, FPSCR 
IT GT 

VMOVGT . F64 D16, D17 

VMOV RO, R1, D16 

BX LR 


Presque comme dans l'exemple précédent, toutefois légèrement différent. Comme 
nous le savons déjà, en mode ARM, beaucoup d'instructions peuvent avoir un prédi- 
cat de condition. Mais il n'y a rien de tel en mode Thumb. Il n'y a pas d'espace dans 
les instructions sur 16-bit pour 4 bits dans lesquels serait encodée la condition. 


Toutefois, cela à été étendu en un mode Thumb-2 pour rendre possible de spécifier 
un prédicat aux instructions de l'ancien mode Thumb. Ici, dans le listing généré par 
IDA, nous voyons l'instruction VMOVGT, comme dans l'exemple précédent. 


En fait, le VMOV usuel est encodé ici, mais IDA lui ajoute le suffixe -GT, puisque que 
l'instruction IT GT se trouve juste avant. 


L'instruction IT défini ce que l'on appelle un bloc if-then. 


Aprés cette instruction, il est possible de mettre jusqu'à 4 instructions, chacune 
d'entre elles ayant un suffixe de prédicat. Dans notre exemple, IT GT implique que 
l'instruction suivante ne sera exécutée que si la condition GT (Greater Than plus 
grand que) est vraie. 


Voici un exemple de code plus complexe, à propos, d'Angry Birds (pour iOS) : 


Listing 1.221 : Angry Birds Classic 


ITE NE 


VMOVNE R2, R3, D16 
VMOVEQ R2, R3, D17 


BLX _objc msgSend ; not suffixed 


ITE est l'acronyme de if-then-else et elle encode un suffixe pour les deux prochaines 
instructions. 


La premiére instruction est exécutée si la condition encodée dans ITE (NE, not equal) 
est vraie, et la seconde—si la condition n'est pas vraie (l'inverse de la condition NE 
est EQ (equal)). 


L'instruction qui suit le second VMOV (ou VMOVEQ) est normale, non suffixée (BLX). 


Un autre exemple qui est légérement plus difficile, qui est aussi d'Angry Birds: 
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Listing 1.222 : Angry Birds Classic 


ITTTT EQ 


MOVEQ RO, R4 

ADDEQ SP, SP, #0x20 
POPEQ.W {R8,R10} 
POPEQ {R4-R7, PC} 


BLX ___stack_chk_ fail ; not suffixed 


Les quatre symboles «T» dans le mnémonique de l'instruction signifient que les 
quatre instructions suivantes seront exécutées si la condition est vraie. 


C'est pourquoi IDA ajoute le suffixe -EQ à chacune d'entre elles. 


Et si il y avait, par exemple, ITEEE EQ (if-then-else-else-else), alors les suffixes se- 
raient mis comme suit: 


-EQ 
-NE 
-NE 
-NE 


Un autre morceau de code d'Angry Birds: 


Listing 1.223 : Angry Birds Classic 


CMP.W RO, £OxFFFFFFFF 


ITTE LE 

SUBLE.W R10, RO, £1 

NEGLE RO, RO 

MOVGT R10, RO 

MOVS R6, #0 ; not suffixed 


CBZ RO, loc 1bE7E32 ; not suffixed 


ITTE (if-then-then-else) 


implique que les 1ère et 2ème instructions seront exécutées si la condition LE (Less 
or Equal moins ou égal) est vraie, et que la 3ème—si la condition inverse (GT— 
Greater Than plus grand que) est vraie. 


En général, les compilateurs ne générent pas toutes les combinaisons possible. 


Par exemple, dans le jeu Angry Birds mentionné ((classic version pour iOS) seules 
les les variantes suivantes de l'instruction IT sont utilisées: IT, ITE, ITT, ITTE, ITTT, 
ITTTT. Comment savoir cela? Dans IDA, il est possible de produire un listing dans 
un fichier, ce qui a été utilisé pour en créer un avec l'option d'afficher 4 octets pour 
chaque opcode. Ensuite, en connaissant la partie haute de l'opcode de 16-bit (OxBF 
pour IT), nous utilisons grep ainsi: 


cat AngryBirdsClassic.lst | grep " BF" | grep "IT" > results.lst 
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À propos, si vous programmez en langage d'assemblage ARM pour le mode Thumb-2, 
et que vous ajoutez des suffixes conditionnels, l'assembleur ajoutera automatique- 
ment l'instruction IT avec les flags là oü ils sont nécessaires. 


sans optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Listing 1.224 : sans optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


b - -0x20 
a - -0x18 
val to return  - -0x10 
saved R7 = -4 
STR R7, [SP,#saved R7]! 
MOV R7, SP 
SUB SP, SP, #0x1C 
BIC SP, SP, #7 
VMOV D16, R2, R3 
VMOV D17, RO, R1 
VSTR D17, [SP,#0x20+a] 
VSTR D16, [SP,#0x20+b] 
VLDR D16, [SP,#0x20+a] 
VLDR D17, [SP,#0x20+b] 
VCMPE.F64 D16, D17 
VMRS APSR nzcv, FPSCR 
BLE loc 2bE08 
VLDR D16, [SP,#0x20+a] 
VSTR D16, [SP,#0x20+val to return] 
B loc 2E10 
loc 2bE08 
VLDR D16, [SP,#0x20+b] 
VSTR D16, [SP,#0x20+val to return] 
loc 2E10 
VLDR D16, [SP,#0x20+val to return] 
VMOV RO, R1, D16 
MOV SP, R7 
LDR R7, [SP+0x20+b] ,#4 
BX LR 


Presque la méme chose que nous avons déja vu, mais ici il y a beaucoup de code 
redondant car les variables a et b sont stockées sur la pile locale, tout comme la 
valeur de retour. 


avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.225 : avec optimisation Keil 6/2013 (Mode Thumb) 


PUSH {R3-R7,LR} 
MOVS R4, R2 
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MOVS R5, R3 

MOVS R6, RO 

MOVS R7, R1 

BL . aeabi cdrcmple 
BCS loc 1C0 

MOVS RO, R6 

MOVS R1, R7 

POP (R3-R7,PC) 


loc 1C0 
MOVS RO, R4 
MOVS R1, R5 
POP {R3-R7,PC} 


Keil ne génére pas les instructions pour le FPU car il ne peut pas étre súr qu’elles sont 
supportées sur le CPU cible, et cela ne peut pas étre fait directement en comparant 
les bits. Donc il appelle une fonction d'une bibliotheque externe pour effectuer la 
comparaison:  aeabi cdrcmple. 


N.B. Le résultat de la comparaison est laissé dans les flags par cette fonction, donc 
l'instruction BCS (Carry set—Greater than or equal plus grand ou égal) fonctionne 
sans code additionnel. 

ARM64 


GCC (Linaro) 4.9 avec optimisation 


d max: 

; DO - a, D1 - b 
fcmpe d0, dl 
fcsel dO, dO, dl, gt 

; maintenant le résultat est dans DO 
ret 


L'ARM64 ISA posséde des instructions FPU qui mettent les flags CPU APSR au lieu de 
FPSCR, par commodité. Le FPU n'est plus un device séparé (au moins, logiquement). 
Ici, nous voyons FCMPE. Ceci compare les deux valeurs passées dans DO et D1 (qui 
sont le premier et le second argument de la fonction) et met les flags APSR (N, Z, C, 
V). 


FCSEL (Floating Conditional Select (sélection de flottant conditionnelle) copie la va- 
leur de DO ou D1 dans DO suivant le résultat de la comparaison (GT—Greater Than), 
et de nouveau, il utilise les flags dans le registre APSR au lieu de FPSCR. 


Ceci est bien plus pratique, comparé au jeu d'instructions des anciens CPUs. 


Si la condition est vraie (GT), alors la valeur de DO est copiée dans DO (i.e., il ne se 
passe rien). Si la condition n'est pas vraie, la valeur de D1 est copiée dans DO. 


GCC (Linaro) 4.9 sans optimisation 
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d_max: 
; sauver les arguments en entrée dans la "Register Save Area" 
; "zone de sauvegarde des registres" 


sub sp, sp, £16 
str d0, [sp,8] 
str dl, [sp] 


; recharger les valeurs 
ldr X1, [sp,8] 
ldr x0, [sp] 
fmov dO, x1 
fmov dl, x0 
; DO - a, D1 - b 
fcmpe d0, dl 
ble .L76 
; a>b; charger DO (a) dans XO 
ldr x0, [sp,8] 
b .L74 
.L76: 
; a<=b; charger D1 (b) dans XO 
ldr x0, [sp] 
.L74: 
; résultat dans X0 
fmov dO, x0 
; résultat dans DO 
add sp, sp, 16 
ret 


GCC sans optimisation est plus verbeux. 


Tout d'abord, la fonction sauve la valeur de ses arguments en entrée dans la pile 
locale (Register Save Area, espace de sauvegarde des registres). Ensuite, le code 
recharge ces valeurs dans les registres X0/X1 et finalement les copie dans DO/D1 afin 
de les comparer en utilisant FCMPE. Beaucoup de code redondant, mais c'est ainsi 
que fonctionne les compilateurs sans optimisation. FCMPE compare les valeurs et 
met les flags du registre APSR. À ce moment, le compilateur ne pense pas encore à 
l'instruction plus commode FCSEL, donc il procéde en utilisant de vieilles méthodes: 
en utilisant l'instruction BLE (Branch if Less than or Equal branchement si inférieur 
ou égal). Dans le premier cas (a » 5), la valeur de a est chargée dans X0. Dans les 
autres cas (a <= b), la valeur de b est chargée dans X0. Enfin, la valeur dans XO est 
copiée dans D6, car la valeur de retour doit étre dans ce registre. 


Exercice 


À titre d'exercice, vous pouvez essayer d'optimiser ce morceau de code manuelle- 
ment en supprimant les instructions redondantes et sans en introduire de nouvelles 
(incluant FCSEL). 


GCC (Linaro) 4.9 avec optimisation—float 
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Ré-écrivons cet exemple en utilisant des float á la place de double. 


float f max (float a, float b) 


1 
if (a»b) 
return a; 
return b; 
}; 
f_max: 


; SO - a, S1 -b 
fcmpe s0, s1 
fcsel sO, sO, sl, gt 

; maintenant le résultat est dans SO 
ret 


C'est le méme code, mais des S-registres sont utilisés à la place de D-registres. C'est 
parce que les nombres de type float sont passés dans des S-registres de 32-bit (qui 
sont en fait la partie basse des D-registres 64-bit). 


MIPS 


Le coprocesseur du processeur MIPS posséde un bit de condition qui peut étre mis 
par le FPU et lu par le CPU. 


Les premiers MIPSs avaient seulement un bit de condition (appelé FCCO), les derniers 
en ont 8 (appelés FCC7-FCCO). 


Ce bit (ou ces bits) sont situés dans un registre appelé FCCR. 


Listing 1.226 : avec optimisation GCC 4.4.5 (IDA) 


d max: 
; mettre le bit de condition du FPU si $f14<$f12 (b<a): 
c.lt.d $f14, $f12 
or gat, $zero ; NOP 
; sauter en locret 14 si le bit de condition est mis 
bcit locret 14 
cette instruction est toujours exécutée (mettre la valeur de retour à "a"): 
mov.d $f0, $f12 ; slot de délai de branchement 
cette instruction est exécutée seulement si la branche n'a pas été prise 
; (i.e., si b>=a) 
; mettre la valeur de retour à "b": 
mov.d $f0, $f14 


locret 14: 
jr $ra 
or $at, $zero ; slot de délai de branchement, NOP 


C.LT.D compare deux valeurs. LT est la condition «Less Than» (plus petit que). D 
implique des valeurs de type double. Suivant le résultat de la comparaison, le bit de 
condition FCCO est mis a 1 ou à O. 
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BCIT teste le bit FCCO et saute si le bit est mis à 1. T signifie que le saut sera effectué 
si le bit est mis à 1 («True »). Il y a aussi une instruction BC1F qui saute si le bit n'est 
pas mis (donc est à 0) («False »). 


Dépendant du saut, un des arguments de la fonction est placé dans $FO. 


1.25.8 Quelques constantes 


Il est facile de trouver la représentation de certaines constantes pour des nombres 
encodés au format IEEE 754 sur Wikipédia. Il est intéressant de savoir que 0,0 en 
IEEE 754 est représenté par 32 bits à zéro (pour la simple précision) ou 64 bits à zéro 
(pour la double). Donc pour mettre une variable flottante à 0,0 dans un registre ou 
en mémoire, on peut utiliser l'instruction MOV ou XOR reg, reg. Ceci est utilisable 
pour les structures oü des variables de types variés sont présentes. Avec la fonction 
usuelle memset() il est possible de mettre toutes les variables entiéres à 0, toutes 
les variables booléennes à false, tous les pointeurs à NULL, et toutes les variables 
flottantes (de n'importe quelle précision) à 0,0. 


1.25.9 Copie 


On peut tout d'abord penser qu'il faut utiliser les instructions FLD/FST pour charger 
et stocker (et donc, copier) des valeurs IEEE 754. Néanmoins, la méme chose peut- 
être effectuée plus facilement avec l'instruction usuelle MOV, qui, bien sûr, copie les 
valeurs au niveau binaire. 


1.25.10 Pile, calculateurs et notation polonaise inverse 


Maintenant nous comprenons pourquoi certains anciens calculateurs utilisent la no- 
tation Polonaise inverse. 


Par exemple, pour additionner 12 et 34, on doit entrer 12, puis 34, et presser le signe 
«plus ». 


C'est parce que les anciens calculateurs programmable étaient simplement des im- 
plémentations de machine à pile, et c'était bien plus simple que de manipuler des 
expressions complexes avec parenthéses. 


Un tel calculateur est encore présent dans de nombreuses distributions Unix: dc. 


1.25.11 80 bits? 


Représentation interne des nombres dans le FPU — 80-bit. Nombre étrange, car il 
n'est pas de la forme 2". Il y a une hypothése que c'est probablement dú à des 
raisons historiques—le standard IBM de carte perforée peut encoder 12 lignes de 80 
bits. La résolution en mode texte de 80-25 était aussi trés populaire dans le passé. 


Il y a une autre explication sur Wikipédia: https://en.wikipedia.org/wiki/Extended 
precision. 


Si vous en savez plus, s'il vous plait, envoyez-moi un email: my emails. 
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1.25.12 x64 


Sur la maniére dont sont traités les nombres à virgules flottante en x86-64, lire ici: 
1.38 on page 554. 


1.25.13 Exercices 


* http://challenges.re/60 
* http://challenges.re/61 


1.26 Tableaux 


yy +22 Un tableau est simplement un ensemble de variables en mémoire qui sont 
situées les unes à côté des autres et qui ont le même type??!, 


1.26.1 Exemple simple 


#include <stdio.h> 


int main() 

{ 
int a[20]; 
int i; 


for (i20; i<20; i++) 
a[i]2-i*2; 


for (i20; i<20; i++) 
printf ("a[%d]=%d\n", i, a[il); 


return 0; 


}; 


x86 
MSVC 


Compilons: 


Listing 1.227 : MSVC 2008 


_ TEXT SEGMENT 


i$ = -84 ; size = 4 
_a$ = -80 ; Size = 80 
main PROC 

push ebp 


120AKA «homogener Container ». 
121AKA «container homogéne » 
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mov 
sub 
mov 
jmp 
$LN5@main: 
mov 
add 
mov 
$LN6@main: 
cmp 
jge 
mov 
shl 
mov 
mov 
jmp 
$LN4@main: 
mov 
jmp 
$LN2@main: 
mov 
add 
mov 
$LN3@main: 
cmp 
jge 
mov 
mov 
push 
mov 
push 
push 
call 
add 
jmp 
$LN1@main: 
xor 
mov 
pop 
ret 
_Main 


ebp, esp 

esp, 84 ; 00000054H 
DWORD PTR i$[ebp], 0 
SHORT $LN6@main 


eax, DWORD PTR i$[ebp] 
eax, 1 

DWORD PTR i$[ebp], eax 
DWORD PTR _i$[ebp], 20 ; 00000014H 
SHORT $LN4@main 

ecx, DWORD PTR i$[ebp] 

ecx, 1 

edx, DWORD PTR i$[ebp] 

DWORD PTR _a$[ebp+edx*4], ecx 

SHORT $LN5@main 


DWORD PTR i$[ebp], 0 
SHORT $LN3Gmain 


eax, DWORD PTR i$[ebp] 
eax, 1 

DWORD PTR i$[ebp], eax 
DWORD PTR i$[ebp], 20 ; 00000014H 
SHORT $LN1@main 

ecx, DWORD PTR i$[ebp] 

edx, DWORD PTR _a$[ebp+ecx*4] 

edx 

eax, DWORD PTR i$[ebp] 

eax 

OFFSET $5G2463 

| printf 

esp, 12 ; 
SHORT $LN2@main 


0000000 cH 


eax, eax 
esp, ebp 
ebp 

0 

ENDP 


Rien de très particulier, juste deux boucles: la première est celle de remplissage et la 
seconde celle d'affichage. L'instruction shl ecx, lestutilisée pour la multiplication 
par 2 de la valeur dans ECX, voir à ce sujet ci-après 1.24.2 on page 284. 


80 octets sont alloués sur la pile pour le tableau, 20 éléments de 4 octets. 
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Essayons cet exemple dans OllyDbg. 
Nous voyons comment le tableau est rempli: 


chaque élément est un mot de 32-bit de type int et sa valeur est l'index multiplié 
par 2: 


CPU - main thread, module simple 


66868026 
66868813 

; 20202800 

> BB1SFEFB 

' Ba18FF44 

90000001 

B040338C simple. ð 


t B(FFFFFFFF) 
> B(FFFFFFFF) 
> B(FFFFFFFF) 
BtFFFFFFFF) 
> TEFDDBBBtFFF) 
BtFFFFFFFF) 


LLOCRL. 211 
[ECX*4+EBP-50] 


DWORD PTR SS: [LOCAL. 


21] 


Imm=8 
Stack (QG18FEFG1=96000014 (decimal 
Jump from 461610 


234x000»... = 


Pr ++! 


RETURN from s 


Fig. 1.87: OllyDbg : aprés remplissage du tableau 


Puisque le tableau est situé sur la pile, nous pouvons voir ses 20 éléments ici. 
GCC 


Voici ce que GCC 4.4.1 génére: 
Listing 1.228 : GCC 4.4.1 


public main 
main proc near ; DATA XREF: _start+17 
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var_70 = dword ptr -70h 
var 6C = dword ptr -6Ch 
var 68 - dword ptr -68h 
i2 = dword ptr -54h 
i - dword ptr -4 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 70h 
mov [esp+70h+i], 0 ; i=0 
jmp short loc_804840A 
loc_80483F7: 
mov eax, [esp+70h+i] 
mov edx, [esp+70h+i] 
add edx, edx ; edx=i*2 
mov [espteax*4+70h+i 2], edx 
add [esp+70h+i], 1 ; i++ 
loc 804840A: 
cmp [esp+70h+i], 13h 
jte short loc 80483F7 
mov [esp+70h+i], 0 
jmp short loc 8048441 
loc 804841B: 
mov eax, [esp+70h+i] 
mov edx, [espteax*4+70h+i 2] 
mov eax, offset aADD ; “al%d]=%d\n" 
mov [esp+70h+var 68], edx 
mov edx, [esp+70h+i] 
mov [esp+70h+var_6C], edx 
mov [esp+70h+var_70], eax 
call _ printf 
add [esp+70h+i], 1 
loc_8048441: 
cmp [esp+70h+i], 13h 
jle short loc 804841B 
mov eax, 0 
leave 
retn 
main endp 


À propos, la variable a est de type int* (un pointeur sur un int)—vous pouvez passer 
un pointeur sur un tableau à une autre fonction, mais c'est plus juste de dire qu'un 
pointeur sur le premier élément du tableau est passé (les adresses du reste des 
éléments sont calculées de maniére évidente). 


Si vous indexez ce pointeur en a[idx], il suffit d'ajouter ¡dx au pointeur et l'élément 
placé ici (sur lequel pointe le pointeur calculé) est renvoyé. 
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Un exemple intéressant: une chaíne de caractéres comme string est un tableau de 
caractères et a un type const char[]. 


Un index peut aussi étre appliqué a ce pointeur. 


Et c'est pourquoi il est possible d'écrire des choses comme «string»[i]—c'est une 
expression C/C++ correcte! 


ARM 


sans optimisation Keil 6/2013 (Mode ARM) 


EXPORT 
main 
STMFD 
SUB 
int 


; premiére boucle 


MOV 
B 
loc 494 
MOV 
STR 
SP+R4*4) 
ADD 
loc 4A0 
CMP 
BLT 
boucle 


; seconde boucle 


MOV 
B 
loc 4B0 
LDR 
R2=* (SP+R4<<4) 


loc _4C4 


boucle 


ADD 
variables int 
LDMFD 


_main 


SP!, {R4,LR} 
SP, SP, #0x50 ; 


RA, #0 B 
loc 4A0 


RO, R4,LSL#1 ; 
RO, [SP,R4,LSL#2] ; 


R4, R4, #1 ; 


RA, #20 ; 
loc_494 ; 


RA, #0 H 
loc 4C4 


R2, [SP,R4,LSL#2] ; 


R1, R4 
RO, aADD ; 
_ 2printf 

R4, R4, #1 ; 


R4, #20 ; 
loc_4B0 P 


RO, #0 ; 
SP, SP, #0x50 ; 


SP!, {R4,PC} 


allouer de la place pour 20 variables 


RO=R4*2 
stocker RO dans SP+R4<<2 (pareil que 


i=i+1 


i<20? 
oui, effectuer encore le corps de la 


(second argument de printf) 


(pareil que *(SP+R4*4) ) 
(premier argument de printf) Rl=i 
"a[%d]=%sd\n" 


i=i+1 


i<20? 
oui, effectuer encore le corps de la 


valeur à renvoyer 
libérer le chunk, alloué pour 20 
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Le type int nécessite 32 bits pour le stockage (ou 4 octets). 
donc pour stocker 20 variables, int 80 (0x50) octets sont nécessaires. 


C'est pourquoi l'instruction SUB SP, SP, #0x50 dans le prologue de la fonction al- 
loue exactement cet espace sur la pile. 


Dans la première et la seconde boucle, la variable de boucle i| se trouve dans le 
registre R4. 


Le nombre qui doit étre écrit dans le tableau est calculé comme i » 2, ce qui est 
effectivement équivalent à décaler d'un bit vers la gauche, ce que fait l'instruction 
MOV RO, R4,LSL#1. 


STR RO, [SP,R4,LSL#2] écrit le contenu de RO dans le tableau. 


Voici comment le pointeur sur un élément du tableau est calculé: SP pointe sur le 
début du tableau, R4 est i. 


Donc décaler i de 2 bits vers la gauche est effectivement équivalent à la multiplica- 
tion par 4 (puisque chaque élément du tableau a une taille de 4 octets) et ensuite 
on l'ajoute à l'adresse du début du tableau. 


La seconde boucle a l'instruction inverse LDR R2, [SP,R4,LSL#2]. Elle charge la 
valeur du tableau dont nous avons besoin, et le pointeur est calculé de méme. 


avec optimisation Keil 6/2013 (Mode Thumb) 


main 
PUSH (RA,R5,LR) 

; allouer de l'espace pour 20 variables int + une variable supplémentaire 
SUB SP, SP, 40x54 


; premiére boucle 


MOVS RO, #0 2 3 

MOV R5, SP ; pointeur sur le premier élément du tableau 
loc 1CE 

LSLS R1, RO, #1 ; Rl=i<<1 (pareil que i*2) 

LSLS R2, RO, 42 ; R2=i<<2 (pareil que i*4) 

ADDS RO, RO, Z1 ; i=i+1 

CMP RO, +20 ; i«20? 

STR R1, [R5,R2] ; stocker R1 dans *(R5+R2) (pareil que R5+i*4) 

BLT loc 1CE ; oui, i«20, effectuer encore le corps de la 

boucle 


; seconde boucle 


MOVS R4, #0 ; i-0 
loc 1DC 
LSLS RO, R4, #2 ; RO=i<<2 (pareil que i*4) 
LDR R2, [R5,R0] ; charger depuis *(R5+R0) (pareil que R5+1*4) 
MOVS R1, R4 
ADR RO, aADD ; "a[%d]=%d\n" 
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BL 
ADDS 
CMP 
BLT 
boucle 


__2printf 

RA, R4, #1 ; 
R4, #20 ; 
loc_1DC ; 


RO, #0 ; 


; libérer le chunk, alloué pour 
; + une variable supplémentaire 


ADD 
POP 


SP, SP, #0x54 
{R4,R5, PC} 


i=i+1 
i<20? 
oui, i<20, effectuer encore le corps de la 


valeur á renvoyer 
20 variables int 


Le code Thumb est tres similaire. 


Le mode Thumb a des instructions spéciales pour le décalage (comme LSLS), qui 
calculent la valeur a écrire dans le tableau et l'adresse de chaque élément dans le 
tableau. 


Le compilateur alloue légérement plus d'espace sur la pile locale, cependant, les 4 
derniers octets ne sont pas utilisés. 


GCC 4.9.1 sans optimisation (ARM64) 


Listing 1.229 : GCC 4.9.1 sans optimisation (ARM64) 


.LC0: 
.string "“a[%d]=%d\n" 
main: 
; sauver FR et LR sur la stack frame: 
stp x29, x30, [sp, -112]! 
; définir l'environnement de pile (FP=SP) 
add x29, sp, 0 
; initialiser la variable compteur à 0 
; (WZR est le registre qui contient toujours zéro): 


str wzr, [x29,108] 

; sauter au code de test de condition de la boucle: 
b .L2 

.L3: 

; charger la valeur de la variable "i": 
ldr w0, [x29,108] 

; la multiplier par 2: 
Isl w2, w0, 1 

; trouver la place du tableau dans la pile locale: 
add x0, x29, 24 

; charger l'entier 32-bit depuis la pile locale et l'étendre en un 64-bit 

signé: 

ldrsw x1, [x29,108] 


; calculer l'adresse de l'élément 
; et y stocker W2 (i*2): 


(X0+X1<<2=adresse du tableau+i*4) 


str w2, [x0,x1,lsl 2] 
; incrémenter le compteur (i): 

ldr w0, [x29,108] 

add w0, wO, 1 

str w0, [x29,108] 
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.L2: 
; tester si la boucle est finie: 
ldr w0, [x29,108] 


cmp w0, 19 
; sauter en L3 (début du corps de la boucle) si non: 
ble .L3 


La seconde partie de la fonction commence ici. 

mettre la valeur initiale da la variable compteur à 0. 

; à propos, le méme espace est utilisé dans la pile locale, 

; car la méme variable locale (i) est utilisée comme compteur. 


str wzr, [x29,108] 
b .L4 

.L5: 

; calculer l'adresse dans le tableau: 
add x0, x29, 24 


charger la valeur de "i": 
ldrsw x1, [x29,108] 
charger la valeur du tableau à l'adresse (X0-X1««2 = adresse du tableau + 
i*4 
ET w2, [x0,x1,lsl 2] 
charger l'adresse de la chaine "a[%d]=%d\n": 
adrp x0, .LCO 


add x0, x0, :1012:.LC0 
; charger la variable "i" dans W1 et la passer à printf() comme second 
argument : 


ldr wl, [x29,108] 
; W2 contient toujours la valeur de l'élément du tableau qui vient d'étre 


chargée. 
; appeler printf(): 
bl printf 


incrémenter la variable "i": 
ldr w0, [x29,108] 
add w0, wO, 1 
str w0, [x29,108] 


.L4: 
; est-ce fini? 
ldr w0, [x29,108] 


cmp w0, 19 
; sauter au début du corps de la boucle si non: 
ble .L5 
; renvoyer 60 
mov w0, 0 
; restaurer FP et LR: 
ldp x29, x30, [sp], 112 
ret 


MIPS 


La fonction utilise beaucoup de S- registres qui doivent étre préservés, c'est pourquoi 
leurs valeurs sont sauvegardées dans la prologue de la fonction et restaurées dans 
l'épilogue. 


Listing 1.230 : GCC 4.4.5 avec optimisation (IDA) 


349 


main: 

var_70 = -0x70 

var_68 = -0x68 

var_14 = -0x14 

var_10 = -0x10 

var_C = -0xC 

var_8 = -8 

var_4 = -4 

; prologue de la fonction: 
lui $gp, ( gnu local gp >> 16) 
addiu  $sp, -0x80 
la $gp, (__gnu local gp € OxFFFF) 
SW $ra, Ox80+var 4($sp) 
SW $s3, Ox80+var 8($sp) 
SW $s2, Ox80+var_C($sp) 
SW $s1, Ox80+var 10($sp) 
SW $s0, Ox80+var_14($sp) 
sw $gp, Ox80+var 70($sp) 
addiu $s1, $sp, Ox80+var 68 
move $v1, $s1 
move $vO, $zero 


; cette valeur va étre utilisée comme fin de boucle. 
; elle a été pré-calculée par le compilateur GCC à l'étape de la compilation: 


li $a0, 0x28 # '(' 
loc 34: # CODE XREF: main+3C 
; stocker la valeur en mémoire: 

SW $v0, 0($v1) 


incrémenter la valeur à sauver de 2 à chaque itération: 
addiu — $v0, 2 

; fin de boucle atteinte? 
bne $vO, $a0, loc 34 

ajouter 4 à l'adresse dans tous les cas 
addiu  $v1, 4 

; la boucle de remplissage du tableau est finie 

la seconde boucle commence 


la $s3, $LCO # "a[%d]=%d\n" 
; la variable "i" va étre dans $s0: 

move $s0, $zero 

li $s2, 0x14 
loc 54: # CODE XREF: main+70 
; appeler printf(): 

lw $t9, (printf € OxFFFF) ($gp) 

lw $a2, 0($s1) 

move $al, $50 

move $a0, $53 

jalr $t9 


; incrémenter "i": 
addiu  $s0, 1 
lw $gp, Ox80+var 70($sp) 
; Sauter au corps de la boucle si la fin n'est pas atteinte: 
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bne $s0, $s2, loc_54 

; déplacer le pointeur mémoire au prochain mot de 32-bit: 
addiu $s1, 4 

; épilogue de la fonction 


lw $ra, Ox80+var 4($sp) 
move $v0, $zero 

lw $s3, Ox80+var 8($sp) 
lw $s2, Ox80+var C($sp) 
lw $s1, Ox80+var 10($sp) 
lw $s0, Ox80+var_14($sp) 
jr $ra 


addiu $sp, 0x80 


$LCO: .ascii "a[%d]=%d\n"<0> # DATA XREF: main+44 


Quelque chose d'intéressant: il y a deux boucles et la premiére n'a pas besoin de 
i, elle a seulement besoin de i + 2 (augmenté de 2 à chaque itération) et aussi de 
l'adresse en mémoire (augmentée de 4 à chaque itération). 


Donc ici nous voyons deux variables, une (dans $VO) augmentée de 2 à chaque fois, 
et une autre (dans $V1) — de 4. 


La seconde boucle est celle où printf() est appelée et affiche la valeur de à à 
l'utilisateur, donc il y a une variable qui est incrémentée de 1 à chaque fois (dans 
$50) et aussi l'adresse en mémoire (dans $51) incrémentée de 4 à chaque fois. 


Cela nous rappelle l'optimisation de boucle que nous avons examiné avant: 3.10 on 
page 627. 


Leur but est de se passer des multiplications. 


1.26.2 Débordement de tampon 
Lire en dehors des bornes du tableau 


Donc, indexer un tableau est juste array[index]. Si vous étudiez le code généré avec 
soin, vous remarquerez sans doute l'absence de test sur les bornes de l'index, qui 
devrait vérifier si il est inférieur à 20. Que ce passe-t-il si l'index est supérieur à 20? 
C'est une des caractéristiques de C/C++ qui est souvent critiquée. 


Voici un code qui compile et fonctionne: 


#include <stdio.h> 


int main() 

{ 
int a[20]; 
int i; 


for (i=0; i<20; i++) 
a[i]2i*2; 


printf ("a[20]=%d\n", a[20]); 
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return 0; 


}; 


Résultat de la compilation (MSVC 2008) : 
Listing 1.231 : MSVC 2008 sans optimisation 


$SG2474 DB 'a[20]-*sd', 0aH, OOH 


_i$ = -84 ; size = 4 
_a$ = -80 ; size = 80 
main PROC 

push ebp 

mov ebp, esp 


sub esp, 84 
mov DWORD PTR i$[ebp], 0 
jmp SHORT $LN3@main 


$LN2@main: 
mov eax, DWORD PTR i$[ebp] 
add eax, 1 
mov DWORD PTR i$[ebp], eax 
$LN3@main: 


cmp DWORD PTR i$[ebp], 20 

jge SHORT $LNlcmain 

mov ecx, DWORD PTR i$[ebp] 

shl ecx, 1 

mov edx, DWORD PTR i$[ebp] 

mov DWORD PTR _a$[ebp+edx*4], ecx 
jmp SHORT $LN2@main 


$LN1@main: 
mov eax, DWORD PTR _a$[ebp+80] 
push eax 


push OFFSET $SG2474 ; ‘a[20]=%d' 
call DWORD PTR imp printf 


add esp, 8 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

_Main ENDP 

_ TEXT ENDS 

END 


Le code produit ce résultat: 


Listing 1.232 : OllyDbg : sortie sur la console 


a[20]=1638280 


C'est juste quelque chose qui se trouvait sur la pile a cóté du tableau, 80 octets 
aprés le début de son premier élément. 
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Essayons de trouver d'oü vient cette valeur, en utilisant OllyDbg. 


Chargeons et trouvons la valeur située juste aprés le dernier élément du tableau: 


CPU - main thread, module r 


55 PUSH EBP 

SBEC MOU EBP,ESP 

83EC 54 SUB ESP,54 

Cr45 RC BG6Gt MOU DWORD PTR SS: [LOCAL.211,0 
EB 09 JMP SHORT 884801818 

8B45 AC OU EAX, DWORD PTR SS: [LOCAL.21] 
S3ca ai EAX, 1 

8945 RC DWORD PTR SS: CLOCAL.21],EAx 
837D RC 14 DWORD PTR SS: [LOCAL.211,14 
SHORT 8848182C 

ECX, DWORD PTR SS: [LOCAL. 211 


EDX, DWORD PTR SS: [LOCAL. 211 
DWORD PTR SS: LEDX*4*EBP-581, ECX 
SHORT B040100F 
MOU EAX, DWORD PTR SS: LOCAL. 6] 
PUSH EAX 
PUSH OFFSET 00493999 
CALL DWORD PTR DS: C<&MSUCR9G. printf >] LastErr 000 
ADD ESP, 8 : qn 
XOR EAX, EAX 000246 (NO, NB 
MOU ESP, EBP : 


m Ñmmmmm 
ow 


A 


it BLFFFFFFFF) 
BLFFFFFFFF) 

* BLFFFFFFFF) 
TEFDDBBBtFFF) 

t BLFFFFFFFF) 


OOHNNDTO 


empty 


C3 

68 28144000 | PUSH 884801428 

ES 90636086 | CALL 664613EB 

A1 50304000 | MOU EAX, DWORD PTR DS: [493050] 
424 HALOUN MASSA N L 


Stack LOBISFFI41=Ó018FFeS 
EAX=000090014 (decimal 28.) 
Jump from 40101C Err 


. Mask 


2620500». 2 


9? t iatwFftCo 
B f EA“wute 
(tew 

ute pH” 


ber ++: 


RETURN from r. 004i 


Fig. 1.88: OllyDbg : lecture du 20ème élément et exécution de printf() 


Qu'est-ce que c'est? D'après le schéma de la pile, c'est la valeur sauvegardée du 
registre EBP. 
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Exécutons encore et voyons comment il est restauré: 


CPU - main thread, module r 


PUSH_EBP 

MOU EBP,ESP 

SUB ESP,54 

MOU DWORD PTR SL LLOCHE 211,0 
JMP SHORT 964616 

MoU EAX, DUORD PTR SS: [LOCAL.211 


EAX 

DUORD PTR SS: [LOCAL.211,EAX 
DWORD PTR SS:LLOCRL.211,14 
SHORT 8848182C 

ECX, DUORD PTR SS: [LOCAL. 21] EIP 80401043 


EDs DuoRD PTR SS: [LOCAL.21] 
894095 Ba DWORD PTR SS: CEDX*4+EBP-50],ECX 
EB ES JMP SHORT 6646166F 

8B45 00 MOU EAX, DWORD PTR SS: LOCAL. 6] 

5a PUSH EAX 

68 00304000 | PUSH OFFSET 00493008 

FF1S AB204001 CALL DWORD PTR DS: C<&MSUCR99. printf >] 
ADD ESP,8 7 A 

XOR EAX, EAX 8 246 (NO,NB,E,BE, PE,GE, LE) 
MOU ESP,EBP S 

POP EBP 


c3 RETN 

68 28144000 | PUSH 00401428 

ES 290630000 | CALL 664613EB 

Al ord nou EAH, DWORD PTR Ha C4020601 


ØLFFFFFFFF) 
O(FFFFFFFF) 
O(FFFFFFFF) 
BLFFFFFFFF) 
7EFOD@G6( FFF) 
OLFFFFFFFF) 


AONDVO 


oo 
c 


" 


OJH t 40 G 
ce 


Pointer to next SI 
SE handler 


bt ER uus 


use (im 394| RETURN to kernel3; 


RETURN to ntdll.7 


Fig. 1.89: OllyDbg : restaurer la valeur de EBP 


En effet, comment est-ce ca pourrait étre différent? Le compilateur pourrait générer 
du code supplémentaire pour vérifier que la valeur de l'index est toujours entre 
les bornes du tableau (comme dans les langages de programmation de plus haut- 
niveau???) mais cela rendrait le code plus lent. 


Écrire hors des bornes du tableau 


Ok, nous avons lu quelques valeurs de la pile illégalement, mais que se passe-t-il si 
nous essayons d'écrire quelque chose? 


Voici ce que nous avons: 


#include <stdio.h> 


int main() 


122java, Python, etc. 
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{ 
int a[20]; 
int i; 
for (i=0; i<30; i++) 
alil=i; 
return 0; 
}; 
MSVC 


Et ce que nous obtenons: 


Listing 1.233 : MSVC 2008 sans optimisation 


TEXT SEGMENT 


_i$ = -84 ; taille = 4 
_a$ = -80 ; taille = 80 
_main PROC 

push ebp 

mov ebp, esp 


sub esp, 84 
mov DWORD PTR i$[ebp], 0 
jmp SHORT $LN3@main 


$LN2@main: 

mov eax, DWORD PTR _i$[ebp] 
add eax, 1 

mov DWORD PTR i$[ebp], eax 
$LN3@main: 


cmp DWORD PTR i$[ebp], 30 ; 0000001eH 
jge SHORT $LN1@main 
mov ecx, DWORD PTR  i$[ebp] 


mov edx, DWORD PTR i$[ebp] ; cette instruction est évidemment 
redondante TUA pow 
mov DWORD PTR _a$[ebp+ecx*4], edx ; ECX pourrait être utilisé en second 


opérande ici 
jmp SHORT $LN2@main 


$LN1@main: 

xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

main  ENDP 


Le programme compilé plante aprés le lancement. Pas de miracle. Voyons exacte- 
ment ou il plante. 
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Chargeons le dans OllyDbg, et tracons le jusqu'à ce que les 30 éléments du tableau 
soient écrits: 


CPU - main thread, module w 


EE pyram 
SUB ESP: 54 EAX BOBDODAD 


00401003 
ETE "ne BHOR? Soils co 212° pom 
8040100F U EAS DWORD PTR SS: CLOCAL. 211 EBX 02920209 
00401012 EA, 1 
Go4eleis| > 8370 AC 1E T. PIR SS; (LOCAL: 211,18. 
0040101 7D ac SHORT 80401024 S 00405572 w. 00480337C 
00401101E 8B4D AC ECX, DWORD PTR LOCRL.211 8040102F w.0040102F 
8B55 AC EDX, DWORD PTR LOCAL : 21] eon It BL EFFEFEFED 
89548D BO DWORD PTR SS: LECX*4«EBP- 501, EDX acb t MAEEEEEEEDA 
EB ES MP SHORT 9040100F SEDIE BIETEFFETE) 
HOR EGR. EOS 32bit B(FFFFFFFF) 
HOS See 32bit 7EFDDGGB(FFF) 
ILE 2 | ; obit BLFFFFFFFF) 


204010s0|f. 68 14144000 | PUSH 00401414 " 
oe4oioss||- ES 90030000 | CALL 48491307 Last Er OS E SUCCESS 
Go4o105H||- A1 40304900 | MOU EAX, DWORD PTR DS: [493940] 00000246 (NO,NB,E, BE, NS, PE, GE, LE) 


aa4aia3F C?8424 203041 MOU DWORD PTR SS: aot @1,0FFSET 004031 - empty 
00401046 FF35 3C304001 PUSH DWORD PTR DS:[40303C] Arad 


[0018FF4387=00000015 


NIN DA es 


> 


68491824 
68491820 


Bet 


8 


4 
LJ 

uT aaisFEFS 

yiHcHGERbB Hf OBISFEFC 


añu ODISFFOG 
GG18FF A4 
G918FF0S 
GG18FFAC 
@G18FF1G 
GG18FF14 
G018FF18 
BB1BFFiC 
GG18FF20 
BB18FF24 
Ba18FF28 
BB1BFF2C 
GG18FF 30 
OB1SFF34 
BB18FF38 
Q818FF3C 
BB18FF4ü 
REZA 
aatSFFAS E 
Er yE ETE 
OBISFFSO 
GG18FFS4 
GG18FFSE 
@18FFSC 
OBISFFGÓ 
BB18FF64 
DOLSEESS 


=p. via 0 E] - E 


ETE. 


ABISFFSS 
we 001S3FF74| CBS9B877 


ax 


Fig. 1.90: OllyDbg : aprés avoir restauré la valeur de EBP 
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Exécutons pas a pas jusqu'a la fin de la fonction: 


CPU - main thread [Of x! 
= 


mim mm mmm m misa 


BtFFFFFFFF) 
BCFFFFFFFF) 
@( FFFFFFFF) 
OLFFFFFFFE) 
7EFDDGGO( FFF) 
BCFFFFFFFF) 


DANDO 


BO ERROR SUCCE 
E, GE, LE) 


Pointer to nes 
SE handler 


RETURN to kernels: 


RETURN to ntdll.7' 


C C 


inter to next SI 


SE handler 


El 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
El 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
El 
4 
El 
4 
4 


Fig. 1.91: OllyDbg : EIP a été restauré, mais OllyDbg ne peut pas désassembler en 
0x15 


Maintenant, gardez vos yeux sur les registres. 


EIP contient maintenant 0x15. Ce n'est pas une adresse légale pour du code—au 
moins pour du code win32! Nous sommes arrivés ici contre notre volonté. Il est aussi 
intéressant de voir que le registre EBP contient 0x14, ECX et EDX contiennent Ox1D. 


Étudions un peu plus la structure de la pile. 


Aprés que le contróle du flux a été passé à main(), la valeur du registre EBP a été 
sauvée sur la pile. Puis, 84 octets ont été alloués pour le tableau et la variable i. 
C'est (20+1)*sizeof(int). ESP pointe maintenant sur la variable i dans la pile 
locale et aprés l'exécution du PUSH quelquechose suivant, quelquechose apparait 
à côté de i. 


C'est la structure de la pile pendant que le contrôle est dans main() : 
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ESP 4 octets alloués pour la variable ; 
ESP+4 | 80 octets alloués pour le tableau a[20] 
ESP+84 | valeur sauvegardée de EBP 

ESP+88 | adresse de retour 


L'expression a[19]=quelquechose écrit le dernier int dans des bornes du tableau 
(dans les limites jusqu’ici!) 


L'expression a[20]=quelquechose écrit quelquechose à l'endroit où la valeur sau- 
vegardée de EBP se trouve. 


S'il vous plait, regardez l'état du registre lors du plantage. Dans notre cas, 20 a été 
écrit dans le 20ème élément. À la fin de la fonction, l'épilogue restaure la valeur 
d'origine de EBP. (20 en décimal est 0x14 en hexadécimal). Ensuite RET est exécuté, 
qui est équivalent à l'instruction POP EIP. 


L'instruction RET prend la valeur de retour sur la pile (c'est l'adresse dans CRT), qui a 
appelé main()), et 21 est stocké ici (0x15 en hexadécimal). Le CPU trape à l'adresse 
0x15, mais il n'y a pas de code exécutable ici, donc une exception est levée. 


Bienvenu! Ca s'appelle un buffer overflow (débordement de tampon)!?. 


Remplacez la tableau de int avec une chaíne (char array), créez délibérément une 
longue chaíne et passez-là au programme, à la fonction, qui ne teste pas la longueur 
de la chaíne et la copie dans un petit buffer et vous serez capable de faire pointer le 
programme à une adresse oü il devra sauter. C'est pas aussi simple dans la réalité, 
mais c'est comme cela que ca a apparu. L'article classique à propos de ca: [Aleph 
One, Smashing The Stack For Fun And Profit, (1996)]?”*. 


GCC 


Essayons le méme code avec GCC 4.4.1. Nous obtenons: 


public main 


main proc near 
a = dword ptr -54h 
i - dword ptr -4 
push ebp 
mov ebp, esp 
sub esp, 60h ; 96 
mov [ebp+i]l, 0 
jmp short loc 80483D1 
loc 80483C3: 
mov eax, [ebp+i] 
mov edx, [ebp+i] 
mov [ebp+eax*4+a], edx 
add [ebp+i1, 1 


loc_80483D1: 


123Wikipédia 
124Aussi disponible en http: //yurichev.com/mirrors/phrack/p49-0x0e.txt 
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cmp [ebp+i], 1Dh 
jle short loc_80483C3 
mov eax, 0 
leave 
retn 
main endp 


Lancer ce programme sous Linux donnera: Segmentation fault. 


Si nous le lancons dans le débogueur GDB, nous obtenons ceci: 


(gdb) r 
Starting program: /home/dennis/RE/1 


Program received signal SIGSEGV, Segmentation fault. 
0x00000016 in ?? () 
(gdb) info registers 


eax 0x0 0 

ecx 0xd2f96388 - 755407992 
edx Ox1d 29 

ebx 0x26eff4 2551796 

esp Oxbffff4bO Oxbffff4bO 
ebp 0x15 0x15 

esi 0x0 0 

edi 0x0 0 

eip 0x16 0x16 

eflags 0x10202 [ IF RF ] 

CS 0x73 115 

ss 0x7b 123 

ds 0x7b 123 

es 0x7b 123 

fs 0x0 0 

gs 0x33 51 

(gdb) 


Les valeurs des registres sont légerement différentes de l'exemple win32, puisque 
la structure de la pile est également légerement différente. 


1.26.3 Méthodes de protection contre les débordements de 
tampon 


Il existe quelques méthodes pour protéger contre ce fléau, indépendamment de la 
négligence des programmeurs C/C++. MSVC posséde des options comme??? : 


/RTCs Stack Frame runtime checking 
/GZ Enable stack checks (/RTCs) 


Une des méthodes est d'écrire une valeur aléatoire entre les variables locales sur la 
pile dans le prologue de la fonction et de la vérifier dans l'épilogue, avant de sortir 


P5méthode de protection contre les débordements de tampons côté compila- 
teur:wikipedia.org/wiki/Buffer overflow protection 
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de la fonction. Si la valeur n'est pas la méme, ne pas exécuter la derniére instruction 
RET, mais stopper (ou bloquer). Le processus va s'arréter, mais c'est mieux qu'une 
attaque distante sur votre ordinateur. 


Cette valeur aléatoire est parfois appelé un «canari», c'est lié au canari*?? que les 
mineurs utilisaient dans le passé afin de détecter rapidement les gaz toxiques. 


Les canaris sont trés sensibles aux gaz, ils deviennent trés agités en cas de danger, 
et méme meurent. 


Si nous compilons notre exemple de tableau trés simple (1.26.1 on page 341) dans 
MSVC avec les options RTC1 et RTCs, nous voyons un appel à @ RTC CheckStackVars@8 
une fonction à la fin de la fonction qui vérifie si le «canari » est correct. 


Voyons comment GCC gére ceci. Prenons un exemple alloca() (1.9.2 on page 49) : 


#ifdef | GNUC — 

#include «alloca.h» // GCC 
#else 

#include <malloc.h> // MSVC 
#endif 

#include <stdio.h> 


void f() 


{ 

char *buf=(char*)alloca (600); 
#ifdef | GNUC __ 

snprintf (buf, 600, "hi! %d, %d, %d\n", 1, 2, 3); // GCC 
#else 

_snprintf (buf, 600, "hi! %d, %d, %d\n", 1, 2, 3); // MSVC 
#endif 


puts (buf); 


}; 


Par défaut, sans option supplémentaire, GCC 4.7.3 insère un test de «canari» dans 
le code: 


Listing 1.234 : GCC 4.7.3 


.LC0: 
.String "hi! %d, %d, %d\n" 
f: 
push ebp 
mov ebp, esp 
push ebx 
sub esp, 676 
lea ebx, [esp+39] 
and ebx, -16 
mov DWORD PTR [esp+20], 3 
mov DWORD PTR [esp+16], 2 
mov DWORD PTR [esp+12], 1 
mov DWORD PTR [esp+8], OFFSET FLAT:.LCO ; "hi! %d, %d, %d\n" 


126 wikipedia.org/wiki/Domestic_canary#Miner.27s_canary 
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mov DWORD PTR [esp+4], 600 
mov DWORD PTR [esp], ebx 
mov eax, DWORD PTR gs:20 ; canari 
mov DWORD PTR [ebp-12], eax 
xor eax, eax 
call _snprintf 
mov DWORD PTR [esp], ebx 
call puts 
mov eax, DWORD PTR [ebp-12] 
xor eax, DWORD PTR gs:20 ; teste le canari 
jne .L5 
mov ebx, DWORD PTR [ebp-4] 
leave 
ret 
.L5: 
call . stack chk fail 


La valeur aléatoire se trouve en gs:20. Elle est écrite sur la pile et à la fin de la 
fonction, la valeur sur la pile est comparée avec le «canari» correct dans gs : 20. Si 
les valeurs ne sont pas égales, la fonction stack chk fail est appelée et nous 
voyons dans la console quelque chose comme ca (Ubuntu 13.04 x86) : 


*** buffer overflow detected ***: ./2 1 terminated 


======= Backtrace: ========= 
/1ib/i386-linux-gnu/libc. 
/lib/i386-linux-gnu/libc. 
/1ib/i386-linux-gnu/libc. 
/1ib/i386-linux-gnu/libc. 
/1ib/i386-linux-gnu/libc. 
/1ib/i386-linux-gnu/libc. 
/1ib/i386-linux-gnu/libc. 


./2 1[0x8048404] 


/11b/i386-linux-gnu/libc. 


so 


. fortify fail+0x63)[0xb7699bc3] 
+0x10593a) [0xb769893a] 
+0x105008) [0xb7698008] 


_10 vfprintf+0x165) [0xb75d7a45] 
. vsprintf chk«0xc9)[0xb76980d9] 
. Sprintf chk«0x2f) [0xb7697fef] 


6 ( 
6 ( 
6 ( 
.6( IO default _xsputn+0x8c) [0xb7606e5c] 
e( 
6 ( 
6 ( 


.6(_ libc start main+0xf5) [0xb75ac935] 


08048000-08049000 r-xp 00000000 08:01 2097586 /home/dennis/2_1 
08049000-0804a000 r--p 00000000 08:01 2097586 /home/dennis/2_1 
0804a000-0804b000 rw-p 00001000 08:01 2097586 /home/dennis/2_1 
094d1000-094f2000 rw-p 00000000 00:00 0 [heap] 
b7560000-b757b000 r-xp 00000000 08:01 1048602 /Vib/i386-linux-gnu/ ? 


y libgcc s.so.1 


b757b000-b757c000 r--p 0001a000 08:01 1048602 /Vib/i386-linux-gnu/ ? 


y libgcc s.so.1 


b757c000-b757d000 rw-p 0001b000 08:01 1048602 /V1ib/i386-linux-gnu/ ? 


y libgcc s.so.1 


b7592000-b7593000 rw-p 00000000 00:00 0 
b7593000-b7740000 r-xp 00000000 08:01 1050781 /V1ib/i386-linux-gnu/libc 


& -2.17.s0 


b7740000-b7742000 r--p 001ad000 08:01 1050781 /Vib/i386-linux-gnu/libc + 


& -2.17.s0 


b7742000-b7743000 rw-p 001af000 08:01 1050781 /Vib/i386-linux-gnu/libc + 


& -2.17.s0 


b7743000-b7746000 rw-p 00000000 00:00 0 
b775a000-b775d000 rw-p 00000000 00:00 0 
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b775d000-b775e000 r-xp 00000000 00:00 0 [vdso] 

b775e000-b777e000 r-xp 00000000 08:01 1050794 /11b/i386-linux-gnu/ld 
V -2.17.s0 

b777e000-b777f000 r--p 0001f000 08:01 1050794 /11b/i386-linux-gnu/ld 
V -2.17.s0 

b777f000-b7780000 rw-p 00020000 08:01 1050794 /11b/i386-linux-gnu/ld 
V -2.17.50 

bff35000-bff56000 rw-p 00000000 00:00 0 [stack] 

Aborted (core dumped) 


gs est ainsi appelé registre de segment. Ces registres étaient beaucoup utilisés du 
temps de MS-DOS et des extensions de DOS. Aujourd'hui, sa fonction est différente. 


Dit brièvement, le registre gs dans Linux pointe toujours sur le TLS*?” (6.2 on page 965)— 
des informations spécifiques au thread sont stockées là. À propos, en win32 le re- 
gistre fs joue le méme rôle, pointant sur TIB12® 129, 


Il y a plus d'information dans le code source du noyau Linux (au moins dans la ver- 
sion 3.11), dans 

arch/x86/include/asm/stackprotector.h cette variable est décrite dans les commen- 
taires. 


avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


Reprenons notre exemple de simple tableau (1.26.1 on page 341), 


à nouveau, nous pouvons voir comment LLVM teste si le «canari » est correct: 


main 

var 64 = -0x64 
var_60 = -0x60 
var 5C = -0x5C 
var 58 = -0x58 
var_54 = -0x54 
var_50 = -0x50 
var 4C = -0x4C 
var_48 = -0x48 
var_44 = -0x44 
var_40 = -0x40 
var 3C = -0x3C 
var 38 = -0x38 
var 34 = -0x34 
var 30 = -0x30 
var 2C - -0x2C 
var 28 - -0x28 
var 24 = -0x24 
var 20 - -0x20 
var 1C = -0x1C 


127Thread Local Storage 
128Thread Information Block 
129wikipedia.org/wiki/Win32_Thread_Information_Block 
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var_18 
canary 
var_10 


-0x18 
-0x14 
-0x10 


{R4-R7,LR} 


SP, #0xC 
[SP,#0xC+var_ 10]! 
SP, #0x54 

#a0bjc methtype ; 


[SP,#0x64+canari] 
#2 
[SP,#0x64+var 64] 
[SP,#0x64+var 60] 
#4 
[SP,#0x64+var 5C] 
#6 
[SP,#0x64+var 58] 
#8 
[SP,#0x64+var 54] 
#0xA 
[SP,#0x64+var 50] 
#0xC 
[SP,#0x64+var 4C] 
#0xE 
[SP,#0x64+var 48] 
#0x10 
[SP,#0x64+var 44] 
#0x12 
[SP,#0x64+var 40] 
#0x14 
[SP,#0x64+var 3C] 
#0x16 
[SP,#0x64+var 38] 
#0x18 
[SP,#0x64+var 34] 
#0x1A 
[SP,#0x64+var 30] 
#0x1C 
[SP,#0x64+var 2C] 
#0x1E 
[SP,#0x64+var 28] 
#0x20 
[SP,#0x64+var 24] 
#0x22 
[SP,#0x64+var 20] 
#0x24 
[SP,#0x64+var 1C] 


"objc methtype" 
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MOVS RO, #0x26 

STR RO, [SP,#0x64+var_18] 
MOV RA, OxFDA ; "a[%d]=w%d1n" 
MOV RO, SP 

ADDS R6, RO, #4 

ADD R4, PC 

B loc 2F1C 


; début de la seconde boucle 


loc 2F14 
ADDS RO, R5, #1 
LDR.W R2, [R6,R5,LSL#2] 
MOV R5, RO 
loc 2F1C 
MOV RO, R4 
MOV R1, R5 
BLX | printf 
CMP R5, 40x13 
BNE loc 2F14 
LDR.W RO, [R8] 
LDR R1, [SP,#0x64+canari] 
CMP RO, R1 
ITTTT EQ ; est-ce que le canari est toujours correct? 


MOVEQ RO, #0 

ADDEQ SP, SP, 40x54 

LDREQ.W R8, [SP+0x64+var_64] ,#4 
POPEQ {R4-R7,PC} 

BLX |. Stack chk fail 


Tout d'abord, on voit que LLVM a «déroulé » la boucle et que toutes les valeurs sont 
écrites une par une, pré-calculée, car LLVM a conclu que c'est plus rapide. À propos, 
des instructions en mode ARM peuvent aider à rendre cela encore plus rapide, et les 
trouver peut étre un exercice pour vous. 


À la fin de la fonction, nous voyons la comparaison des «canaris »—celui sur la pile 
locale et le correct. 


S'ils sont égaux, un bloc de 4 instructions est exécuté par ITTTT EQ, qui contient 
l'écriture de O dans RO, l'épilogue de la fonction et la sortie. Si les «canaris» ne 
sont pas égaux, le bloc est passé, et la fonction saute en stack chk fail, qui, 
peut-étre, stoppe l'exécution. 


1.26.4 Encore un mot sur les tableaux 


Maintenant nous comprenons pourquoi il est impossible d'écrire quelque chose comme 
ceci en code C/C++: 


void f(int size) 
1 


int a[size]; 
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PE 


C'est simplement parce que le compilateur doit connaítre la taille exacte du tableau 
pour lui allouer de l'espace sur la pile locale lors de l'étape de compilation. 


Si vous avez besoin d'un tableau de taille arbitraire, il faut l'allouer en utilisant 
malloc(), puis en accédant aux blocs de mémoire allouée comme un tableau de 
variables du type dont vous avez besoin. 


Ou utiliser la caractéristique du standart C99 [ISO/IEC 9899:TC3 (C C99 standard), 
(2007)6.7.5/2], et qui fonctionne comme alloca() (1.9.2 on page 49) en interne. 


Il est aussi possible d'utiliser des bibliothéques de ramasse-miettes pour C. 


Et il y a aussi des bibliothéques supportant les pointeurs intelligents pour C++. 


1.26.5 Tableau de pointeurs sur des chaînes 
Voici un exemple de tableau de pointeurs.130 


Listing 1.235 : Prendre le nom du mois 


#include <stdio.h> 


const char* month1[]= 


{ 

"janvier", "fevrier", "mars", "avril", 

"mai", "juin", "juillet", "aout", 

"septembre", "octobre", "novembre", "decembre" 
}; 


// dans l'intervalle 0..11 
const char* get monthl (int month) 


return month1 [month]; 


x64 


Listing 1.236 : MSVC 2013 avec optimisation x64 


DATA | SEGMENT 


monthl DQ FLAT: $5G3122 
DQ FLAT: $5G3123 
DQ FLAT: $5G3124 
DQ FLAT: $5G3125 
DQ FLAT: $5G3126 
DQ FLAT: $5G3127 
DQ FLAT: $5G3128 
DQ FLAT: $5G3129 


130NDT: attention à l'encodage des fichiers, en ASCII ou en ISO-8859, un caractére occupe un octet, alors 
qu'en UTF-8, notamment, il peut en occuper plusieurs. Par exemple, 'ü' est codé $fb (1 octet) en ISO-8859 
et $c3$bb (2 octets) en UTF-8. J'ai donc volontairement mis des caractéres non accentués dans le code. 
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DQ FLAT: $5G3130 

DQ FLAT: $5G3131 

DQ FLAT: $5G3132 

DQ FLAT: $5G3133 
$SG3122 DB 'January', 00H 
$5G3123 DB 'February', 00H 
$SG3124 DB 'March', 00H 
$SG3125 DB 'April', 00H 
$SG3126 DB 'May', 00H 
$SG3127 DB 'June', 00H 
$SG3128 DB 'July', 00H 
$5G3129 DB 'August', 00H 
$5G3130 DB 'September', 00H 
$SG3156 DB '%5', OaH, OOH 
$5G3131 DB 'October', 00H 
$5G3132 DB 'November', 00H 
$5G3133 DB 'December', 00H 
_DATA ENDS 
month$ = 8 


get_month1 PROC 


movsxd rax, ecx 


lea rcx, OFFSET FLAT:month1 
mov rax, QWORD PTR [rcx+rax*8] 
ret 0 


get monthl ENDP 


Le code est trés simple: 


La premiére instruction MOVSXD copie une valeur 32-bit depuis ECX (oü l'argu- 
ment month est passé) dans RAX avec extension du signe (car l'argument month 
est de type int). 


La raison de l'extension du signe est que cette valeur 32-bit va étre utilisée 
dans des calculs avec d'autres valeurs 64-bit. 


C'est pourquoi il doit être étendu à 64-bit??!, 
Ensuite l'adresse du pointeur de la table est chargée dans RCX. 


Enfin, la valeur d'entrée (month) est multipliée par 8 et ajoutée à l'adresse. Effec- 
tivement: nous sommes dans un environnement 64-bit et toutes les adresses 
(ou pointeurs) nécessitent exactement 64 bits (ou 8 octets) pour étre stockées. 
C'est pourquoi chaque élément de la table a une taille de 8 octets. Et c'est pour- 
quoi pour prendre un élément spécifique, month + 8 octets doivent étre passés 
depuis le début. C'est ce que fait MOV. De plus, cette instruction charge égale- 
ment l'élément à cette adresse. Pour 1, l'élément sera un pointeur sur la chaîne 
qui contient «février », etc. 


131C'est parfois bizarre, mais des indices négatifs de tableau peuvent étre passés par month (les indices 
négatifs de tableaux sont expliqués plus loin: 3.22 on page 769). Etsi cela arrive, la valeur entrée négative 
de type int est étendue correctement et l'élément correspondant avant le tableau est sélectionné. Ca ne 
fonctionnera pas correctement sans l'extension du signe. 
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GCC 4.9 avec optimisation peut faire encore mieux??? : 


Listing 1.237 : GCC 4.9 avec optimisation x64 


movsx rdi, edi 
mov rax, QWORD PTR month1[0+rdi*8] 
ret 


MSVC 32-bit 


Compilons-le aussi avec le compilateur MSVC 32-bit: 


Listing 1.238 : MSVC 2013 avec optimisation x86 


_month$ = 8 

get monthl PROC 
mov eax, DWORD PTR month$[esp-4] 
mov eax, DWORD PTR monthil[eax*4] 
ret 0 


get month1 ENDP 


La valeur en entrée n'a pas besoin d'étre étendue sur 64-bit, donc elle est utilisée 
telle quelle. 


Et elle est multipliée par 4, car les éléments de la table sont larges de 32-bit (ou 4 
octets). 


ARM 32-bit 
ARM en mode ARM 


Listing 1.239 : avec optimisation Keil 6/2013 (Mode ARM) 
get monthl PROC 


LDR r1,|L0.100| 
LDR ro,[r1,ro,LsL #2] 
BX lr 
ENDP 

|LO.100| 
DCD || .data] | 
DCB "January", 
DCB "February" ,0 
DCB "March" ,0 
DCB "April",0 
DCB "May",0 
DCB "June",0 
DCB "July",0 


132«0.- » a été laissé dans le listing car la sortie de l'assembleur GCC n'est pas assez soignée pour 
l'éliminer. C'est un déplacement, et il vaut zéro ici. 
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DCB "August",0 

DCB "September", 0 

DCB "October",0 

DCB "November" ,0 

DCB "December",0 

AREA ||.data||, DATA, ALIGN=2 
month1 

DCD conststring|| 

DCD conststring| |+0x8 

DCD conststring| |+0x11 

DCD conststring| |+0x17 

DCD conststring | |+0x1d 

DCD conststring| |+0x21 


RE 
RE 
|I. 
|I. 
|I. 
[|. 
DCD | | .conststring | |+0x26 
|I. 
[|. 
|. 
|I. 
|I. 


DCD conststring| |+0x2b 
DCD conststring | |+0x32 
DCD conststring | |+0x3c 
DCD conststring | |+0x44 
DCD conststring | |+0x4d 


L'adresse de la table est chargée en R1. 
Tout le reste est effectué en utilisant juste une instruction LDR. 


Puis la valeur en entrée est décalée de 2 vers la gauche (ce qui est la méme chose 
que multiplier par 4), puis ajoutée à R1 (où se trouve l'adresse de la table) et enfin 
un élément de la table est chargé depuis cette adresse. 


L'élément 32-bit de la table est chargé dans R1 depuis la table. 


ARM en mode Thumb 


Le code est essentiellement le méme, mais moins dense, car le suffixe LSL ne peut 
pas étre spécifié dans l'instruction LDR ici: 


get monthl PROC 


LSLS r0,r0,#2 
LDR r1,|L0.64] 
LDR ro,[r1,r0] 
BX lr 

ENDP 


ARM64 
Listing 1.240 : GCC 4.9 avec optimisation ARM64 
get monthl: 
adrp X1, .LANCHORO 
add X1, x1, :1012:.LANCHORO 
ldr x0, [x1,w0,sxtw 3] 


ret 
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. LANCHORO = . +0 
.type | monthl, “object 
.Size monthl, 96 


month1: 

.xword .LC2 

.xword .LC3 

.xword .LC4 

.xword .LC5 

.xword .LC6 

.xword .LC7 

.xword .LC8 

.Xword .LC9 

.xword .LC10 

.xword .LC11 

.xword .LC12 

.xword .LC13 
.LC2: 

.string "January" 
.LC3: 

.string "February" 
.LC4: 

.string "March" 
.LC5: 

.string "April" 
.LC6: 

.string "May" 
.LC7: 

.string "June" 
.LC8: 

.string "July" 
.LC9: 

.string "August" 
.LC10: 

.string "September" 
.LC11: 

.string "October" 
.LC12: 

.string "November" 
.LC13: 


.string "December" 


L'adresse de la table est chargée dans X1 en utilisant la paire ADRP/ADD. 


Puis l'élément correspondant est choisi dans la table en utilisant seulement un LDR, 
qui prend WO (le registre où l'argument d'entrée month se trouve), le décale de 3 
bits vers la gauche (ce qui est la méme chose que de le multiplier par 8), étend son 
signe (c'est ce que le suffixe «sxtw » implique) et l'ajoute à XO. Enfin la valeur 64-bit 
est chargée depuis la table dans XO. 


MIPS 
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Listing 1.241 : GCC 4.4.5 avec optimisation (IDA) 


get_monthl: 


; charger 
; prendre 
; ajouter 
; charger 


; Sortir 


month1: 


aJanuary: 
aFebruary: 
aMarch: 
aApril: 
aMay : 
aJune: 
aJuly: 
aAugust: 


aSeptember: 


aOctober: 
aNovember: 
aDecember: 


l'adresse de 


la 


la valeur en 


sll 


l'adresse de 


addu 


l'élément de 


lw 


jr 
or 


la table dans $v0: 

$v0, monthl 

entrée et la multiplier par 4: 
$a0, 2 

la table et la valeur multipliée: 
$a0, $v0 

la table á cette adresse dans $v0: 
$v0, 0($a0) 


$ra 
$at, $zero ; 


.data £ .data.rel.local 
.globl month1 


.word 
.word 
.word 
.word 
.word 
.word 
.word 
.word 
.word 
.word 
.word 
.word 


.data 

.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 
.ascii 


aJanuary # "janvier" 
aFebruary # "fevrier" 
aMarch # "mars" 
aApril # "avril" 
aMay # "mai" 
aJune # "juin" 
aJuly # "juillet" 
aAugust # "aout" 
aSeptember # "septembre" 
a0ctober # "octobre" 
aNovember # "novembre" 
aDecember # "decembre" 
# .rodata.str1.4 

"janvier"<0> 

"fevrier"<0> 

"mars"<0> 

"avril"<0> 

"mai"<0> 

"juin"«0- 

"juillet"<0> 

"aout"<0> 

"septembre"<0> 

"octobre"«0» 

"novembre" «0» 

"decembre" «0» 


slot de délai de branchement, NOP 


Débordement de tableau 


Notre fonction accepte des valeurs dans l'intervalle 0..11, mais que se passe-t-il si 
12 est passé? Il n'y a pas d'élément dans la table à cet endroit. 


Donc la fonction va charger la valeur qui se trouve là, et la renvoyer. 


Peu aprés, une autre fonction pourrait essayer de lire une chaine de texte depuis 
cette adresse et pourrait planter. 
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Compilons l'exemple dans MSVC pour win64 et ouvrons le dans IDA pour voir ce que 
l'éditeur de lien à stocker aprés la table: 


Listing 1.242 : Fichier exécutable dans IDA 


off 140011000 dq offset aJanuary 1 ; DATA XREF: .text:0000000140001003 
; "January" 
dq offset aFebruary 1 ; "February" 
dq offset aMarch 1 ; "March" 
dq offset aApril 1 ; "April" 
dq offset aMay 1 ; "May" 
dq offset aJune 1 ; "June" 
dq offset aJuly 1 "July" 
dq offset aAugust 1 ; "August" 
dq offset aSeptember 1 ; "September" 
dq offset aOctober 1 ; "October" 
dq offset aNovember 1 ; "November" 
dq offset aDecember 1  ; "December" 
aJanuary 1 db 'January',0 ; DATA XREF: sub_140001020+4 
; .data:off 140011000 
aFebruary 1 db 'February',0 ; DATA XREF: .data:0000000140011008 
align 4 
aMarch 1 db 'March',0 ; DATA XREF: .data:0000000140011010 
align 4 
aApril 1 db 'April',0 ; DATA XREF: .data:0000000140011018 


Les noms des mois se trouvent juste aprés. 


Notre programme est minuscule, il n'y a donc pas beaucoup de données à mettre 
dans le segment de données, juste les noms des mois. Mais il faut noter qu'il peut y 
avoir ici vraiment n'importe quoi que l'éditeur de lien aurait décidé d'y mettre. 


Donc, que se passe-t-il si nous passons 12 à la fonction? Le 13éme élément va étre 
renvoyé. 


Voyons comment le CPU traite les octets en une valeur 64-bit: 


Listing 1.243 : Fichier exécutable dans IDA 


off 140011000 dq offset qword 140011060 
; DATA XREF: .text:0000000140001003 


dq offset aFebruary 1 ; "February" 

dq offset aMarch 1 ; "March" 

dq offset aApril 1 ; "April" 

dq offset aMay 1 ; "May" 

dq offset aJune 1 ; "June" 

dq offset aJuly 1 ; "July" 

dq offset aAugust 1 ; "August" 

dq offset aSeptember 1 ; "September" 

dq offset aOctober 1 ; "October" 

dq offset aNovember 1 ; "November" 

dq offset aDecember 1  ; "December" 
qword 140011060 dq 797261756E614Ah ; DATA XREF: sub_140001020+4 


; .data:off 140011000 
aFebruary 1 db 'February',0 ; DATA XREF: .data:0000000140011008 
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align 4 
aMarch_1 db 'March',0 ; DATA XREF: .data:0000000140011010 


Et c'est 0x797261756E614A. 


Peu aprés, une autre fonction (supposons, une qui traite des chaínes) pourrait es- 
sayer de lire des octets à cette adresse, y attendant une chaíne-C. 


Plus probablement, ca planterait, car cette valeur ne ressemble pas à une adresse 
valide. 


Protection contre les débordements de tampon 


Si quelque chose peut mal tourner, ca 
tournera mal 


Loi de Murphy 
Il est un peu naïf de s'attendre à ce que chaque programmeur qui utilisera votre 
fonction ou votre bibliothéque ne passera jamais un argument plus grand que 11. 


Il existe une philosophie qui dit «échouer tót et échouer bruyamment » ou «échouer 
rapidement », qui enseigne de remonter les problémes le plus tót possible et d'arré- 
ter. 


Une telle méthode en C/C++ est les assertions. 


Nous pouvons modifier notre programme pour qu'il échoue si une valeur incorrecte 
est passée: 


Listing 1.244 : assert() ajoutée 


const char* get monthl checked (int month) 
1 
assert (month<12) ; 
return month1[month]; 
}; 


La macro assertion vérifie que la validité des valeurs à chaque démarrage de fonction 
et échoue si l'expression est fausse. 


Listing 1.245 : MSVC 2013 x64 avec optimisation 


$SG3143 DB 'm', 00H, 'o', 00H, 'n', 00H, 't', 00H, 'h', 00H, '.', 00H 
DB 'c', 00H, OOH, OOH 

$SG3144 DB 'm', 00H, 'o', OOH, 'n', 00H, 't', OOH, 'h', OOH, '<', 00H 
DB '1', 00H, '2', OOH, OOH, OOH 

month$ - 48 

get monthl checked PROC 

$LN5: 
push rbx 
sub rsp, 32 


movsxd rbx, ecx 
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cmp ebx, 12 
jl SHORT $LN3Gget monthl 
lea rdx, OFFSET FLAT:$SG3143 
lea rcx, OFFSET FLAT:$SG3144 
mov r8d, 29 
call  wassert 

$LN3Gget monthl: 
lea rcx, OFFSET FLAT:month1 
mov rax, QWORD PTR [rcx+rbx*8] 
add rsp, 32 
pop rbx 
ret 0 


get monthl checked ENDP 


En fait, assert() n'est pas une fonction, mais une macro. Elle teste une condition, 
puis passe le numéro de ligne et le nom du fichier à une autre fonction qui rapporte 
cette information à l'utilisateur. 


Ici nous voyons qu'à la fois le nom du fichier et la condition sont encodés en UTF-16. 
Le numéro de ligne est aussi passé (c'est 29). 


Le mécanisme est sans doute le méme dans tous les compilateurs. Voici ce que fait 
GCC: 


Listing 1.246 : GCC 4.9 x64 avec optimisation 


.LC1: 

.string "month.c" 
.LC2: 

.string "month<12" 


get monthl checked: 


cmp edi, 11 
jg .L6 
movsx rdi, edi 
mov rax, QWORD PTR month1[0+rdi*8] 
ret 
.L6: 
push rax 
mov ecx, OFFSET FLAT: PRETTY FUNCTION .2423 
mov edx, 29 
mov esi, OFFSET FLAT:.LC1 
mov edi, OFFSET FLAT:.LC2 
call . assert fail 


. PRETTY FUNCTION .2423: 
.string "get monthl checked" 


Donc la macro dans GCC passe aussi le nom de la fonction par commodité. 
Rien n'est vraiment gratuit, et c'est également vrai pour les tests de validité. 


Ils rendent votre programme plus lent, en particulier si la macro assert() est utilisée 
dans des petites fonctions à durée critique. 
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Donc MSCV, par exemple, laisse les tests dans les compilations debug, mais ils dis- 
paraissent dans celles de release. 


Les noyaux de Microsoft Windows NT existent en versions «checked » et «free ». 133, 


Le premier a des tests de validation (d’ou, «checked »), le second n'en a pas (d’ou, 
«free/libre » de tests). 


Bien sûr, le noyau «checked » fonctionne plus lentement à cause de ces tests, donc 
il n'est utilisé que pour des sessions de debug. 
Accéder à un caractére spécifique 


Un tableau de pointeurs sur des chaînes peut être accédé comme ceci!”* : 


#include <stdio.h> 


const char* month[]= 


{ 
"janvier", "fevrier", "mars", "avril", 
"mai", "juin", "juillet", "aout", 
"septembre", "octobre", "novembre", "decembre" 
}; 
int main() 
1 
// 4eme mois, 5éme caractére: 
printf ("%c\n", month[3][4]); 
i 


...puisque l'expression month[3] a un type const char*. Et donc, le 5ème caractère 
est extrait de cette expression en ajoutant 4 octets à cette adresse. 


À propos, la liste d'arguments passée à la fonction main() a le méme type de don- 
nées: 


#include <stdio.h> 


int main(int argc, char *argv[]) 


{ 
}; 


printf ("3ème argument, 2ème caractère: %c\n", argv[3][1]); 


Il est très important de comprendre, que, malgré la syntaxe similaire, c'est différent 
d'un tableau à deux dimensions, dont nous allons parler plus tard. 


Une autre chose importante à noter: les chaînes considérées doivent être encodées 
dans un système où chaque caractère occupe un seul octet, comme l'ASCII ou 
l'ASCII étendu. UTF-8 ne fonctionnera pas ici. 


133msdn.microsoft.com/en-us/library/windows/hardware/ff543450(v=vs.85).aspx 
134] jsez l'avertissement dans la NDT ici 1.26.5 on page 364 
135American Standard Code for Information Interchange 
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1.26.6 Tableaux multidimensionnels 


En interne, un tableau multidimensionnel est pratiquement la méme chose qu'un 
tableau linéaire. 


Puisque la mémoire d'un ordinateur est linéaire, c'est un tableau uni-dimensionnel. 
Par commodité, ce tableau multidimensionnel peut facilement étre représenté comme 
un uni-dimensionnel. 


Par exemple, voici comment les éléments du tableau 3*4 sont placés dans un tableau 
uni-dimensionnel de 12 éléments: 


Offset en mémoire | élément du tableau 
[01[0] 
[0111] 
[01121 
[01131 
[11101 
[1111] 
[1112] 
[1113] 
[2110] 
[2111] 
0 [21121 
1 [21131 


H| e| O| ©) | O) UT) S UJ NI e| © 


Tab. 1.3: Tableau en deux dimensions représenté en mémoire en une dimension 


Voici comment chacun des éléments du tableau 3*4 sont placés en mémoire: 


01 2 3 
41516 |7 
8 9/10 11 


Tab. 1.4: Adresse mémoire de chaque élément d'un tableau a deux dimensions 


Donc, afin de calculer l'adresse de l'élément voulu, nous devons d'abord multiplier 
le premier index par 4 (largeur du tableau) et puis ajouter le second index. Ceci est 
appelé row-major order (ordre ligne d'abord), et c'est la méthode de représentation 
des tableaux et des matrices au moins en C/C++ et Python. Le terme row-major 
order est de l'anglais signifiant: « d'abord, écrire les éléments de la premiére ligne, 
puis ceux de la seconde ligne ...et enfin les éléments de la derniére ligne ». 


Une autre méthode de représentation est appelée column-major order (ordre co- 
lonne d'abord) (les indices du tableau sont utilisés dans l'ordre inverse) et est utilisé 
au moins en ForTran, MATLAB et R. Le terme column-major order est de l'anglais 
signifiant: « d'abord, écrire les éléments de la premiére colonne, puis ceux de la 
seconde colonne ...et enfin les éléments de la derniére colonne ». 


Quelle méthode est la meilleure? 
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En général, en termes de performance et de mémoire cache, le meilleur schéma 
pour l'organisation des données est celui dans lequel les éléments sont accédés 
séquentiellement. 


Donc si votre fonction accéde les données par ligne, row-major order est meilleur, 
et vice-versa. 


Exemple de tableau à 2 dimensions 


Nous allons travailler avec un tableau detype char, qui implique que chaque élément 
n'a besoin que d'un octet en mémoire. 


Exemple de remplissage d'une ligne 


Remplissons la seconde ligne avec les valeurs 0..3: 


Listing 1.247 : Exemple de remplissage d'une ligne 


#include <stdio.h> 
char a[3][4]; 


int main() 


{ 


int x, y; 


// effacer le tableau 
for (x=0; x<3; X++) 
for (y=0; y<4; y++) 
alx1[y1=0; 


// remplir la 2ème ligne avec 0..3 
for (y=0; y«4; y++) 
a[1][y]-y; 
}; 


Les trois lignes sont entourées en rouge. Nous voyons que la seconde ligne a main- 
tenant les valeurs 0, 1, 2 et 3: 


Address | Hen dump 0 


4 
a 
G 


apatía D 


ooo 


m 


Exemple de remplissage d'une colonne 


Remplissons la troisiéme colonne avec les valeurs: 0..2: 
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Listing 1.248 : Exemple de remplissage d'une colonne 


#include <stdio.h> 
char a[3][4]; 


int main() 


{ 


int x, y; 


// effacer le tableau 
for (x=0; x<3; x++) 
for (y=0; y<4; y++) 
alx] [y]=0; 


// remplir la troisiéme colonne avec 0..2: 
for (x=0; x<3; X++) 
alx1[21=x; 
}; 


Les trois lignes sont entourées en rouge ici. 


Nous voyons que dans chaque ligne, à la troisième position, ces valeurs sont écrites: 
0, 1 et 2. 


Ba aa 61 66/66 aa be 66J02 aa Be 66 
HH HA Ba aa as gä 


Ba aa 66 as ag aa ag 66 GB GO GB dB 
Ba 66 66 66 GB 66 66 66 06 G^ A dB 


De 


aoe 
De Lu Lu) 


Fig. 1.93: OllyDbg : le tableau est rempli 


Accéder à un tableau en deux dimensions comme un à une dimension 


Nous pouvons facilement nous assurer qu'il est possible d'accéder à un tableau en 
deux dimensions d'au moins deux façons: 


#include <stdio.h> 
char a[3][4]; 


char get by coordinatesl (char array[3][4], int a, int b) 


1 
}; 


return array[a][b]; 


char get by coordinates2 (char *array, int a, int b) 


// traiter le tableau en entrée comme uni-dimensionnel 
// 4 est ici la largeur du tableau 
return array[a*4+b]; 


}; 


char get by coordinates3 (char *array, int a, int b) 
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1 
// traiter le tableau en entrée comme un pointeur 
// calculer l'adresse, y prendre une valeur 
// 4 est ici la largeur du tableau 
return *(array+a*4+b); 
$; 
int main() 
1 
a[2][3]=123; 
printf ("%d\n", get by coordinatesl(a, 2, 3)); 
printf ("%d\n", get by coordinates2(a, 2, 3)); 
printf ("%d\n", get by coordinates3(a, 2, 3)); 
$; 


Compilons??? le et lançons le: il montre des valeurs correctes. 


Ce que MSVC 2013 a généré est fascinant, les trois routines sont les mémes! 


Listing 1.249 : MSVC 2013 avec optimisation x64 


array$ = 8 
a$ = 16 
b$ = 24 


get by coordinates3 PROC 
; RCX=adresse du tableau 
; RDX=a 
; R8=b 
movsxd rax, r8d 
; EAX=b 
movsxd r9, edx 
; R9=a 
add rax, rcx 
; RAX=b+adresse du tableau 
movzx eax, BYTE PTR [rax+r9*4] 
; AL=charger l'octet à l'adresse RAX+R9*4=b+adresse du tableau+a*4=adresse du 


tableau+a*4+b 
ret 


get by coordinates3 ENDP 


array$ = 8 
a$ = 16 
b$ = 24 


get by coordinates2 PROC 
movsxd rax, r8d 
movsxd r9, edx 


add rax, rcx 
movzx eax, BYTE PTR [rax+r9*4] 
ret 0 


get by coordinates2 ENDP 


array$ = 8 


136Ce programme doit étre compilé comme un programme C, pas C++, sauvegardez-le dans un fichier 
avecl'extention .c pour le compiler avec MSVC 
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a$ = 16 

b$ = 24 

get by coordinatesl PROC 
movsxd rax, r8d 
movsxd r9, edx 


add rax, rcx 
movzx eax, BYTE PTR [rax+r9*4] 
ret 0 


get by coordinatesl ENDP 


GCC génére des routines équivalentes, mais légérement différentes: 


Listing 1.250 : GCC 4.9 x64 avec optimisation 


; RDI=adresse du tableau 
; RSI=a 
; RDX=b 


get by coordinatesl: 
; étendre le signe sur 64-bit des valeurs 32-bit en entrée "a" et "b" 
movsx rsi, esi 
movsx rdx, edx 
lea rax, [rdi+rsi*4] 
; RAX=RDI+RSI*4=adresse du tableau+a*4 
movzx eax, BYTE PTR [rax+rdx] 
; AL=charger l'octet à l'adresse RAX+RDX=adresse du tableau+a*4+b 
ret 


get by coordinates2: 


lea eax, [rdx+rsi*4] 
; RAX=RDX+RSI*4=b+a*4 
cdqe 


movzx eax, BYTE PTR [rdi+rax] 
; AL=charger l'octet à l'adresse RDI+RAX=adresse du tableau+b+a*4 
ret 


get by coordinates3: 
sal esi, 2 

; EST=a<<2=a*4 

; étendre le signe sur 64-bit des valeurs 32-bit en entrée "a*4" et "p" 
movsx rdx, edx 
movsx rsi, esi 
add rdi, rsi 

; RDI=RDI+RSI=adresse du tableau+a*4 
movzx eax, BYTE PTR [rdi+rdx] 

; AL=charger l'octet à l'adresse RDI+RAX=adresse du tableau+a*4+b 
ret 


Exemple de tableau à trois dimensions 


C'est la méme chose pour des tableaux multidimensionnels. 
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Nous allons travailler avec des tableaux de type int : chaque élément nécessite 4 


Octets en mémoire. 


Voyons ceci: 


Listing 1.251 : simple exemple 


#include <stdio.h> 


int a[10][20] [30]; 


void insert(int x, int y, int z, int value) 


{ 
}; 


alx1[y][z]=value; 


x86 


Nous obtenons (MSVC 2010) : 


Listing 1.252 : MSVC 2010 
DATA SEGMENT 
COMM . a:DWORD : 01770H 
DATA ENDS 
PUBLIC insert 
TEXT SEGMENT 
x$ 28 ; taille = 4 
y$ = 12 ; taille = 4 
_z$ = 16 ; taille = 4 
_value$ = 20 ; taille = 4 
_insert PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _x$[ebp] 
imul eax, 2400 ; eax=600*4*x 
mov ecx, DWORD PTR _y$[ebp] 
imul ecx, 120 ; ecx=30*4*y 
lea edx, DWORD PTR _a[eax+ecx] ; edx=a + 600*4*x + 30*4*y 
mov eax, DWORD PTR _z$[ebp] 
mov ecx, DWORD PTR _value$[ebp] 
mov DWORD PTR [edx+eax*4], ecx ; *(edx+z*4)=valeur 
pop ebp 
ret 0 
_insert ENDP 
_TEXT ENDS 


Rien de particulier. Pour le calcul de l'index, trois arguments en entrée sont utilisés 
dans la formule address = 600 -4-x+30-4-y+4z, pour représenter le tableau comme 
multidimensionnel. N’oubliez pas que le type int est 32-bit (4 octets), donc tous les 


coefficients doivent étre multipliés par 4. 
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Listing 1.253 : GCC 4.4.1 


public insert 
insert proc near 


x = dword ptr 8 
y = dword ptr OCh 
Z = dword ptr 10h 
value = dword ptr 14h 
push ebp 
mov ebp, esp 
push ebx 
mov ebx, [ebp+x] 
mov eax, [ebp+y] 
mov ecx, [ebp+z] 
lea edx, [eax+eax] ; edx=y*2 
mov eax, edx ; eax=y*2 
shl eax, 4 ; eax=(y*2)<<4 = y*2*16 = y*32 
sub eax, edx ; eaxzy*32 - y*2=y*30 
imul edx, ebx, 600 ; edx=x*600 
add eax, edx ; eax=eax+edx=y*30 + x*600 
lea edx, [eax+ecx] ; edx=y*30 + x*600 + z 
mov eax, [ebp+value] 
mov dword ptr ds:a[edx*4], eax ; *(a+edx*4)=valeur 
pop ebx 
pop ebp 
retn 


insert endp 


Le compilateur GCC fait cela différemment. 


Pour une des opérations du calcul (30y), GCC produit un code sans instruction de 
multiplication. Voici comment il fait: (y + y) «4- (y + y) = (2y) « 4- 2y = 2- 16 - y - 2y = 
32y - 2y = 30y. Ainsi, pour le calcul de 30y, seulement une addition, un décalage de 
bit et une soustraction sont utilisés. Ceci fonctionne plus vite. 


ARM 4 sans optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


Listing 1.254 : sans optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


insert 

value = -0x10 
Z = -0xC 
y = -8 
Xx = -4 


; allouer de l'espace sur la pile locale pour 4 valeurs de type int 
SUB SP, SP, #0x10 

MOV R9, OxFC2 ; a 

ADD R9, PC 

LDR.W R9, [R9] ; prendre le pointeur sur le tableau 
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STR RO, [SP,#0x10+x] 

STR R1, [SP,#0x10+y] 

STR R2, [SP,#0x10+z] 

STR R3, [SP,#0x10+value] 
LDR RO, [SP,#0x10+value] 
LDR R1, [SP,#0x10+z] 

LDR R2, [SP,#0x10+y] 

LDR R3, [SP,#0x10+x] 

MOV R12, 2400 

MUL.W R3, R3, R12 

ADD R3, R9 

MOV R9, 120 

MUL.W R2, R2, R9 

ADD R2, R3 

LSLS R1, R1, Z2 ; RI-R1««2 
ADD R1, R2 

STR RO, [R1] ; R1 - adresse de l'élément du tableau 


; libérer le chunk sur la pile locale, alloué pour 4 valeurs de type int 
ADD SP, SP, #0x10 
BX LR 


LLVM sans optimisation sauve toutes les variables dans la pile locale, ce qui est 
redondant. 
L'adresse de l'élément du tableau est calculée par la formule vue précédemment. 


ARM + avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


Listing 1.255 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb) 


insert 
MOVW R9, #0x10FC 
MOV.W R12, #2400 
MOVT.W R9, #0 
RSB.W R1, R1, R1,LSL#4 ; R1 - y. Rl=y<<4 - y = y*16 - y = y*15 
ADD R9, PC 
LDR.W R9, [R9] ; R9 = pointeur sur la tableau a 
MLA.W RO, RO, R12, R9 ; RO - x, R12 - 2400, R9 - pointeur sur a. 
RO=x*2400 + ptr sur a 
ADD.W RO, RO, R1,LSL#3 ; RO = RO+R1<<3 = RO+R1*8 = x*2400 + ptr sur a + 
*15*8 = 
” ; ptr sur a + y*30*4 + x*600*4 
STR.W R3, [RO,R2,LSLZ2] ; R2 - z, R3 - valeur. adresse=R0+z*4 = 
; ptr sur a + y*30*4 + x*600*4 + z*4 
BX LR 


L'astuce de remplacer la multiplication par des décalage, addition et soustraction 
que nous avons déjà vue est aussi utilisée ici. 


Ici, nous voyons aussi une nouvelle instruction: RSB (Reverse Subtract). 


Elle fonctionne comme SUB, mais échange ses opérandes l'un avec l'autre avant 
l'exécution. Pourquoi? SUB et RSB sont des instructions auxquelles un coefficient de 
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décalage peut étre appliqué au second opérande: (LSL#4). 
Mais ce coefficient ne peut étre appliqué qu'au second opérande. 


C'est bien pour des opérations commutatives comme l'addition ou la multiplication 
(les opérandes peuvent étre échangés sans changer le résultat). 


Mais la soustraction est une opération non commutative, donc RSB existe pour ces 
cas. 


MIPS 


Mon exemple est minuscule, donc le compilateur GCC a décidé de mettre le tableau 
a dans la zone de 64KiB adressable par le Global Pointer. 


Listing 1.256 : GCC 4.4.5 avec optimisation (IDA) 


insert: 
; $a0=x 
; $al=y 
; $a2-z 
; $a3-valeur 
su $v0, $a0, 5 
; $vO = $a0««5 = x*32 
su $20, 3 


; $a0 = $a0««3 = x*8 
addu $a0, $v0 
; $a0 = $a0+$v0 = x*8+x*32 = x*40 


sll $v1, fal, 5 
; $v1 = $al<<5 = y*32 

sll $v0, $a0, 4 
; $vO = $a0««4 = x*40*16 = x*640 

su $al, 1 


; $al = $al««1 = y*2 
subu gal, $vl, $al 
; $al = $v1-$al = y*32-y*2 = y*30 
subu $a0, $vO, $a0 
; $a0 = $v0-$a0 = x*640-x*40 = x*600 
la $gp, gnu local gp 
addu $a0, $al, $a0 
; $a0 = $al+$a0 = y*30+x*600 
addu $a0, $a2 
; $a0 = $a0+$a2 = y*30+x*600+z 
charger l'adresse de la table: 


lw $vO, (a € OxFFFF) ($9p) 
; multiplier l'index par 4 pour avancer d'un élément du tableau: 
sll $a0, 2 


ajouter l'index multiplié et l'adresse de la table: 
addu $a0, $v0, $a0 

stocker la valeur dans la table et retourner: 
jr $ra 
SW $a3, 0($a0) 


.comm a:0x1770 
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Obtenir la dimension d'un tableau multidimensionnel 


Toute fonction de traitement de chaîne, à laquelle un tableau de caractère lui est 
passée, ne peut pas en déduire la taille de ce tableau en entrée. 


Par exemple: 


int get element(int array[10][20], int x, int y) 


1 
return array[x][y]; 
}; 
int main() 
{ 
int array[10][20]; 
get element(array, 4, 5); 
}; 


Si compilé (par n'importe quel compilateur) et ensuite décompilé par Hex-Rays: 


int get element(int *array, int x, int y) 


{ 
} 


return array[20 * x + y]; 


Il n'y a pas moyen de trouver la taille de la première dimension. Si la valeur x pas- 
sée est trop grosse, un dépassement de tampon peut se produire, un élément d'un 
endroit aléatoire en mémoire sera lu. 


Et un tableau 3D: 


int get element(int array[10][20][30], int x, int y, int z) 
1 


return array[x][yl[z]; 


}; 

int main() 

: int array[10] [20] [30]; 
get_element(array, 4, 5, 6); 

}; 

Hex-Rays: 


int get element(int *array, int x, int y, int z) 


{ 
} 


return array[600 * x + z + 30 * y]; 


À nouveau, seules deux des 3 dimensions peuvent être déduites. 
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Plus d'exemples 


L'écran de l'ordinateur est représenté comme un tableau 2D, mais le buffer vidéo 
est un tableau linéaire 1D. Nous en parlons ici: 8.15.2 on page 1184. 


Un autre exemple dans ce livre est le jeu Minesweeper: son champ est aussi un 
tableau à deux dimensions: 8.4 on page 1047. 


1.26.7 Ensemble de chaines comme un tableau à deux dimen- 
sions 


Retravaillons la fonction qui renvoie le nom d'un mois: listado.1.235. 


Comme vous le voyez, au moins une opération de chargement en mémoire est né- 
cessaire pour préparer le pointeur sur la chaine représentant le nom du mois. 


Est-il possible de se passer de cette opération de chargement en mémoire? 


En fait oui, si vous représentez la liste de chaines comme un tableau à deux dimen- 
sions: 


#include <stdio.h> 
#include <assert.h> 


const char month2[12][10]= 


{ 
{ 'j','a','n','v','i','e','r', 0, 0, 0 }, 
{ 'f','e','b','v','r','i',' ME 0, 0 }, 
{ ‘m','a','s', 0, 0, 0, 0, 0, 0, 0 }, 
{ 'a ut E, 0, 0, 0, 0, 0 }, 
{ 'm','a','i', 0, 0, 0, 0, 0, 0, 0}, 
1 'j','u','i','n', 0, 0, 0, 0, 0, 0 }, 
{ jt, tu" it Ur, Ut, le" st", 0, 0, 0 }, 
{ 'a','o','u','t', 0, 0, 0, 0, 0, 0 }, 
{ 'S','e','p','t' 'e','m','b','r','e', 0 }, 
{ "o, Cc V t'; 0 "D^ rs tet, 0, 0, 0 Is 
{ 'n','o','v','e','m','b','r','e', 0, 0], 
['d','e','c','e','m','b','r','e', 0, 0) 

un 


// dans l'intervalle 0..11 
const char* get month2 (int month) 


1 
}; 


return &month2[month] [0]; 


Voici ce que nous obtenons: 


Listing 1.257 : MSVC 2013 x64 avec optimisation 


month2 DB 04aH 
DB 061H 
DB 06eH 


DB 075H 
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DB 061H 
DB 072H 
DB 079H 
DB 00H 
DB 00H 
DB 00H 


get month2 PROC 
; étendre le signe de l'argument en entrée sur 64-bit 
movsxd rax, ecx 
lea rcx, QWORD PTR [rax+rax*4] 
; RCX=mois+mois*4=mois*5 
lea rax, OFFSET FLAT:month2 
; RAXepointeur sur la table 
lea rax, QWORD PTR [rax+rcx*2] 
; RAX=pointeur sur la table + RCX*2=pointeur sur la table + mois*5*2=pointeur 


sur la table + mois*10 
ret 0 


get_month2 ENDP 


Il n'y a pas du tout d'accès à la mémoire. 


Tout ce que fait cette fonction, c'est de calculer le point oü le premier caractére du 
nom du mois se trouve: pointeur sur la table + mois * 10. 


Il y a deux instructions LEA, qui fonctionnent en fait comme plusieurs instructions 
MUL et MOV. 


La largeur du tableau est de 10 octets. 


En effet, la chaine la plus longue ici—«septembre »—fait 9 octets, plus l'indicateur 
de fin de chaîne O, ca fait 10 octets 


Le reste du nom de chaque mois est complété par des zéros, afin d'occuper le méme 
espace (10 octets). 


Donc, notre fonction fonctionne méme plus vite, car toutes les chaînes débutent à 
une adresse qui peut étre facilement calculée. 


GCC 4.9 avec optimisation fait encore plus court: 


Listing 1.258 : GCC 4.9 x64 avec optimisation 


movsx rdi, edi 


lea rax, [rdi+rdi*4] 
lea rax, month2[rax+rax] 
ret 


LEA est aussi utilisé ici pour la multiplication par 10. 


Les compilateurs sans optimisations générent la multiplication différemment. 


Listing 1.259 : GCC 4.9 x64 sans optimisation 


get month2: 
push rbp 


386 


RDX 


RAX 


RAX 


RAX 


RAX 


RAX 


mov rbp, rsp 
mov DWORD PTR [rbp-4], edi 
mov eax, DWORD PTR [rbp-4] 


MOVSX rdx, eax 
valeur entrée avec signe étendu 


mov rax, rdx 

mois 

sal rax, 2 

mois<<2 = mois*4 

add rax, rdx 

RAX+RDX = mois*4+mois = mois*5 
add rax, rax 

RAX*2 = mois*5*2 = mois*10 

add rax, OFFSET FLAT:month2 
mois*10 + pointeur sur la table 
pop rbp 

ret 


MSVC sans optimisation utilise simplement l'instruction IMUL : 


Listing 1.260 : MSVC 2013 x64 sans optimisation 


month$ = 8 
get_month2 PROC 


, 


RAX 


RAX 


RCX 


RCX 


RAX 


RCX 


RCX 


RAX 


mov DWORD PTR [rsp+8], ecx 

movsxd rax, DWORD PTR month$[rsp] 

étendre le signe de la valeur entrée sur 64-bit 
imul rax, rax, 10 


RAX*10 

lea rcx, OFFSET FLAT:month2 
pointeur sur la table 

add rcx, rax 

RCX+RAX = pointeur sur la table+mois*10 
mov rax, rcx 

pointeur sur la table+mois*10 
mov ecx, 1 

1 

imul rcx, rcx, 0 

1*0 = 0 

add rax, rcx 


pointeur sur la table+mois*10 + 0 = pointeur sur la table+mois*10 


ret 0 


get month2 ENDP 


Mais une chose est est curieuse: pourquoi ajouter une multiplication par zéro et 
ajouter zéro au résultat final? 


Ceci ressemble à une bizarrerie du générateur de code du compilateur, qui n'a pas 
été détectée par les tests du compilateur (le code résultant fonctionne correctement 
aprés tout). Nous examinons volontairement de tels morceaux de code, afin que le 
lecteur prenne conscience qu'il ne doit parfois pas se casser la téte sur des artefacts 
de compilateur. 
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32-bit ARM 


Keil avec optimisation pour le mode Thumb utilise l'instruction de multiplication 
MULS : 


Listing 1.261 : avec optimisation Keil 6/2013 (Mode Thumb) 


; RO = mois 
MOVS r1,#0xa 
; R1 = 10 
MULS ro,r1,ro 
; RO = R1*RO = 10*mois 
LDR r1,|L0.68] 
; R1 = pointer sur la table 
ADDS r0,r0,r1 
; RO = RO+R1 = 10*mois + pointer sur la table 
BX lr 


Keil avec optimisation pour mode ARM utilise des instructions d'addition et de déca- 
lage: 


Listing 1.262 : avec optimisation Keil 6/2013 (Mode ARM) 


; RO = mois 

LDR r1,|L0.104| 
; Rl = pointeur sur la table 

ADD r0,r0,r0,LSL #2 
; RO = RO+RO<<2 = RO+RO*4 = mois*5 

ADD r0,r1,r0,LSL #1 
; RO = R1+RO<<2 = pointeur sur la table + mois*5*2 = pointeur sur la table + 

mois*10 

BX lr 

ARM64 
Listing 1.263 : GCC 4.9 ARM64 avec optimisation 

; WO = mois 

sxtw x0, wO 


; X0 = valeur entrée avec signe étendu 
adrp X1, .LANCHOR1 


add X1, x1, :1012:.LANCHOR1 
; X1 = pointeur sur la table 
add x0, x0, x0, lsl 2 
; X0 = XO+XO<<2 = XO+XO*4 = X0*5 
add x0, x1, x0, 1sl 1 
; X0 = X1+X0<<1 = X1+X0*2 = pointeur sur la table + X0*10 
ret 


SXTW est utilisée pour étendre le signe, convertir l'entrée 32-bit en 64-bit et stocker 
le résultat dans XO. 


La paire ADRP/ADD est utilisée pour charger l'adresse de la table. 


L'instruction ADD a aussi un suffixe LSL, qui aide avec les multiplications. 
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MIPS 
Listing 1.264 : GCC 4.4.5 avec optimisation (IDA) 
.globl get mois2 

get mois2: 

; $a0=mois 


sll $v0, $a0, 3 


; $vO = $a0««3 = mois*8 


sll $a0, 1 


; $a0 = $a0««1 = mois*2 


addu $a0, $v0 


; $a0 = mois*2+mois*8 = mois*10 
; charger l'adresse de la table: 


la $v0, mois2 


; ajouter l'adresse de la table et l'index que nous avons calculé et sortir: 


jr $ra 
addu $v0, $a0 


mois2: .ascii "janvier"<0> 
.byte 0, 0 

aFebruary: .ascii "fevrier"<0> 
.byte 0 

aMarch: .ascii "mars"<0> 
.byte 0, 0, 0, 0 

aApril: .ascii "avril"<0> 
.byte 0, 0, 0, 0 

aMay: .ascii "mai"<0> 
.byte 0, 0, 0, 0, 0, 0 

aJune: „ascii "juin"<0> 
.byte 0, 0, 0, 0, 0 

aJuly: .ascii "juillet"<0> 
.byte 0, 0, 0, 0, 0 

aAugust: „ascii "aout"<0> 
.byte 0, 0, 0 

aSeptember: .ascii "septembre"<0> 

a0ctober: „ascii "octobre"<0> 
.byte 0, 0 

aNovember: .ascii "novembre"<0> 
. byte 0 

aDecember: ascii "decembre"<0> 
.byte 0, 0, 0, 0, 0, 0, 0, 0, O 

Conclusion 


C'est une technique surannée de stocker des chaínes de texte. Vous pouvez en trou- 
ver beaucoup dans Oracle RDBMS, par exemple. Il est difficile de dire si ca vaut la 
peine de le faire sur des ordinateurs modernes. Néanmoins, c'est un bon exemple 
de tableaux, donc il a été ajouté à ce livre. 
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1.26.8 Conclusion 


Un tableau est un ensemble de données adjacentes en mémoire. 
C'est vrai pour tout type d'élément, structures incluses. 
Pour accéder a un élément spécifique d'un tableau, il suffit de calculer son adresse. 


Donc, un pointeur sur un tableau et l'adresse de son premier élément—sont la méme 
chose. C'est pourquoi les expressions ptr[0] et *ptr sont équivalentes en C/C++. II 
est intéressant de noter que Hex-Rays remplace souvent la premiére par la seconde. 
Il procède ainsi lorsqu'il n'a aucune idée qu'il travaille avec un pointeur sur le tableau 
complet et pense que c'est un pointeur sur une seule variable. 


1.26.9 Exercices 


* http://challenges.re/62 
* http://challenges.re/63 
* http://challenges.re/64 
* http://challenges.re/65 
* http://challenges.re/66 


1.27 Exemple: un bogue dans Angband 


Un ancien jeu rogue-like des années 90 !?7 avait un bogue dans l'esprit de "Roadside 
Picnic"!?? par les frères Strugatsky ou "The Lost Room”, une série TV??? : 


The frog-knows version was abundant of bugs. The funniest of them 
led to a cunning technique of cheating the game, that was called 
"mushroom farming". If there were more than a certain number (about 
five hundred) of objects in the labyrinth, the game would break, and 
many old things turned into objects thrown to the floor. Accordingly, 
the player went into the maze, he made such longitudinal grooves 
there (with a special spell), and walked along the grooves, creating 
mushrooms with another special spell. When there were a lot of mush- 
rooms, the player put and took, put and took some useful item, and 
mushrooms one by one turned into this subject. After that, the player 
returned with hundreds of copies of the useful item. 


(Misha “tiphareth” Verbitsky, http://imperium.lenin.ru/CEBEP/arc/3/lightmusic/ 
light.htm) 


Et d'autres informations provenant de usenet: 


137https://en.wikipedia.org/wiki/Angband (video game), http://rephial.org/ 
138https://en.wikipedia.org/wiki/Roadside Picnic 
139https://en.wikipedia.org/wiki/The_Lost_Room 
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From: be...@uswest.com (George Bell) 
Subject: [Angband] Multiple artifact copies found (bug?) 
Date: Fri, 23 Jul 1993 15:55:08 GMT 


Up to 2000 ft I found only 4 artifacts, now my house is littered with the 

suckers (FYI, most I've gotten from killing nasties, like Dracoliches and 2 
S the 

like). Something really weird is happening now, as I found multiple 

copies of the same artifact! My half-elf ranger is down at 2400 ft on one 

level which is particularly nasty. There is a graveyard plus monsters 

surrounded by permanent rock and 2 or 3 other special monster rooms! I did 

so much slashing with my favorite weapon, Crisdurian, that I filled several 

rooms nearly to the brim with treasure (as usual, mostly junk). 


Then, when I found a way into the big vault, I noticed some of the treasure 

had already been identified (in fact it looked strangely familiar!). Then 2 
VI 

found *two* Short Swords named Sting (1d6) (47,48), and I just ran across a 

third copy! I have seen multiple copies of Gurthang on this level as well. 

Is there some limit on the number of items per level which I have exceeded? 

This sounds reasonable as all multiple copies I have seen come from this 7 
S level. 


I'm playing PC angband. Anybody else had this problem? 
-George Bell 
Help! I need a Rod of Restore Life Levels, if there is such a thing. 2 


S These 
Graveyards are nasty (Black Reavers and some speed 2 wraith in particular). 


(https://groups.google.com/forum/#! original/rec.games.moria/jItmf rdGyL8/ 
8csctQqA7PQJ ) 


From: Ceri <cm...@andrew.cmu.edu> 
Subject: Re: [Angband] Multiple artifact copies found (bug?) 
Date: Fri, 23 Jul 1993 23:32:20 -0400 


welcome to the mush bug. if there are more than 256 items 
on the floor, things start duplicating. learn to harness 
this power and you will win shortly :> 


- -Rick 


( google groups ) 


From: nwe...@soda.berkeley.edu (Nicholas C. Weaver) 
Subject: Re: [Angband] Multiple artifact copies found (bug?) 
Date: 24 Jul 1993 18:18:05 GMT 


In article <74348474...@unixl.andrew.cmu.edu> Ceri <cm...@andrew.cmu.edu> 7 
\ writes: 
>welcome to the mush bug. if there are more than 256 items 
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>on the floor, things start duplicating. learn to harness 
>this power and you will win shortly :> 

> 

>- -Rick 


QUestion on this. Is it only the first 256 items which get 
duplicated? What about the original items? Etc ETc ETc... 


Oh, for those who like to know about bugs, though, the -n option 
(start new character) has the following behavior: 


(this is in version 2.4.Frog.knows on unix) 
If you hit controll-p, you keep your old stats. 
YOu loose all record of artifacts founds and named monsters killed. 


YOu loose all items you are carrying (they get turned into error in 
objid()s ). 


You loose your gold. 
You KEEP all the stuff in your house. 


If you kill something, and then quaff a potion of restore life 
levels, you are back up to where you were before in EXPERIENCE POINTS!! 


Gaining spells will not work right after this, unless you have a 
gain int item (for spellcasters) or gain wis item (for priests/palidans), 7 
V in 
which case after performing the above, then take the item back on and off, 
you will be able to learn spells normally again. 


This can be exploited, if you are a REAL HOZER (like me), into 
getting multiple artifacts early on. Just get to a level where you can 
pound wormtongue into the ground, kill him, go up, drop your stuff in your 
house, buy a few potions of restore exp and high value spellbooks with your 
leftover gold, angband -n yourself back to what you were before, and repeat 
the process. Yes, you CAN kill wormtongue multiple times. :) 


This also allows the creation of a human rogue with dunedain 2 
& warrior 
starting stats. 


Of course, such practices are evil, vile, and disgusting. I take 7 
4 no 
liability for the results of spreading this information. Yeah, it's 7 
y another 
bug to go onto the pile. 


Nicholas C. Weaver perpetual ensign guppy nwe...Gsoda.berkeley. 7 
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S edu 
It is a tale, told by an idiot, full of sound and fury, .signifying 2 
y nothing. 
Since C evolved out of B, and a C+ is close to a B, 
does that mean that C++ is a devolution of the language? 


(https://groups.google.com/forum/#! original/rec.games.moria/jItmf rdGyL8/ 
FoQeiccewHAJ ) 


Le fil de discussion complet. 


J'ai trouvé la version avec le bogue (2.4 fk) 14°, et on peut voir clairement comment 
les tableaux globaux sont déclarés: 


/* Number of dungeon objects */ 
#define MAX DUNGEON OBJ 423 


int16 sorted objects[MAX DUNGEON 0BJ]; 


/* Identified objects flags "y 
int8u object ident[OBJECT IDENT SIZE]; 

int16 t level[MAX 0BJ LEVEL+1]; 

inven type t list[MAX TALLOC] ; 

inven type inventory[INVEN ARRAY SIZE]; 


Peut-étre que ceci est une raison. La constante MAX DUNGEON OBJ est trop petite. 
Peut-être que les auteurs devraient utiliser des listes chaînées ou d'autres structures 
de données, qui ont une taille illimitée. Mais les tableaux sont plus simples à utiliser. 


Un autre exemple de débordement de tampon dans un tableau défini globalement: 
3.31 on page 832. 


1.28 Manipulation de bits spécifiques 


Beaucoup de fonctions définissent leurs arguments comme des flags dans un champ 
de bits. 


Bien sür, ils pourraient étre substitués par un ensemble de variables de type bool, 
mais ce n'est pas frugal. 


1.28.1 Test d'un bit spécifique 


x86 


Exemple avec l'API win32: 
HANDLE fh; 


140http://rephial.org/release/2.4.fk, https://yurichev.com/mirrors/angband-2.4.fk.tar 
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fh=CreateFile ("file", GENERIC WRITE | GENERIC READ, 7 
$ FILE SHARE READ, NULL, OPEN ALWAYS, FILE ATTRIBUTE NORMAL, NULL); 


Nous obtenons (MSVC 2010) : 
Listing 1.265 : MSVC 2010 


push 0 
push 128 ; 00000080H 
push 4 
push 0 
push 1 
push -1073741824 ; C0000000H 


push OFFSET $5G78813 
call DWORD PTR imp CreateFileA@28 
mov DWORD PTR fh$[ebp], eax 


Regardons dans WinNT.h: 
Listing 1.266 : WinNT.h 


#define GENERIC READ (0x80000000L) 
#define GENERIC WRITE (0x40000000L) 
#define GENERIC EXECUTE (0x20000000L) 
define GENERIC ALL (0x10000000L) 


Tout est clair, GENERIC READ | GENERIC WRITE = 0x80000000 | 0x40000000 = 
0xC0000000, et c'est la valeur utilisée comme second argument pour la fonction 
CreateFile()!^. 


Comment CreateFile() va tester ces flags? 


Si nous regardons dans KERNEL32.DLL de Windows XP SP3 x86, nous trouverons ce 
morceau de code dans CreateFilew : 


Listing 1.267 : KERNEL32.DLL (Windows XP SP3 x86) 


.text:7C83D429 test byte ptr [ebp+dwDesiredAccess+3], 40h 
.text:7C83D42D mov [ebp+var 8], 1 

.text:7C83D434 jz short loc 7C83D417 

.text:7C83D436 jmp loc 7C810817 


Ici nous voyons l'instruction TEST, toutefois elle n'utilise pas complétement le second 
argument, mais seulement l'octet le plus significatif et le teste avec le flag 0x40 (ce 
qui implique le flag GENERIC WRITE ici). 


TEST est essentiellement la méme chose que AND, mais sans sauver le résultat (rap- 
pelez vous le cas de CMP qui est la méme chose que SUB, mais sans sauver le résul- 
tat (1.12.4 on page 119)). 


La logique de ce bout de code est la suivante: 


if ((dwDesiredAccess&0x40000000) == 0) goto loc 7C83D417 


141msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx 
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Si l'instruction AND laisse ce bit, le flag ZF sera mis à zéro et le saut conditionnel JZ ne 
sera pas effectué. Le saut conditionnel est effectué uniquement su la bit 0x40000000 
est absent dans la variable dwDesiredAccess —auquel cas le résultat du AND est 0, 
ZF est mis à 1 et le saut conditionnel est effectué. 


Essayons avec GCC 4.4.1 et Linux: 


#include <stdio.h> 
#include <fcntl.h> 


void main() 


t 


int handle; 


handle=open ("file", O_RDWR | O CREAT); 
}; 


Nous obtenons: 


Listing 1.268 : GCC 4.4.1 


public main 


main proc near 
var 20 = dword ptr -20h 
var 1C = dword ptr -1Ch 
var 4 - dword ptr -4 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 20h 
mov [esp+20h+var 1C], 42h 
mov [esp+20h+var_20], offset aFile ; "file" 
call open 
mov [esp+20h+var 4], eax 
leave 
retn 
main endp 


Si nous regardons dans la fonction open() de la bibliothéque Libc.so.6, c'est seule- 
ment un appel systéme: 


Listing 1.269 : open() (libc.so.6) 


.text : 000BE69B mov edx, [esp+4+mode] ; mode 
.text:000BE69F mov ecx, [esp+4+flags] ; flags 

. text :000BE6A3 mov ebx, [esp+4+filename] ; filename 
.text:000BE6A7 mov eax, 5 

.text:000BE6AC int 80h ; LINUX - sys open 


Donc, le champ de bits pour open() est apparemment testé quelque part dans le 
noyau Linux. 
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Bien súr, il est facile de télécharger le code source de la Glibc et du noyau Linux, 
mais nous voulons comprendre ce qui se passe sans cela. 


Donc, à partir de Linux 2.6, lorsque l'appel systeme sys open est appelé, le contróle 
passe finalement à do sys open, et à partir de la—a la fonction do filp open() 
(elle est située ici fs/namei.c dans l'arborescence des sources du noyau). 


N.B. Outre le passage des arguments par la pile, il y a aussi une méthode consistant 
à passer certains d'entre eux par des registres. Ceci est aussi appelé fastcall (6.1.3 
on page 955). Ceci fonctionne plus vite puisque le CPU ne doit pas faire d'accés à la 
pile en mémoire pour lire la valeur des arguments. GCC a l'option regparm?**?, avec 
laquelle il est possible de définir le nombre d'arguments qui peuvent étre passés par 
des registres. 


Le noyau Linux 2.6 est compilé avec l'option -mregparm-3 143 144, 


Cela signifie que les 3 premiers arguments sont passés par les registres EAX, EDX et 
ECX, et le reste via la pile. Bien sür, si le nombre d'arguments est moins que 3, seule 
une partie de ces registres seront utilisés. 


Donc, téléchargeons le noyau Linux 2.6.31, compilons-le dans Ubuntu: make vmlinux, 
ouvrons-le dans IDA, et cherchons la fonction do filp open(). Au début, nous voyons 
(les commentaires sont les miens) : 


Listing 1.270 : do filp open() (noyau Linux kernel 2.6.31) 


do filp open proc near 
push ebp 
mov ebp, esp 
push edi 
push esi 
push ebx 
mov ebx, ecx 
add ebx, 1 
sub esp, 98h 
mov esi, [ebp+arg_4] ; acc mode (5éme argument) 
test bl, 3 
mov [ebp+var 80], eax ; dfd (ler argument) 
mov [ebp+var_7C], edx ; pathname (2ème argument) 
mov [ebp+var_78], ecx ; open flag (3éme argument) 
jnz short loc COIEF684 
mov ebx, ecx ; ebx «- open flag 


GCC sauve les valeurs des 3 premiers arguments dans la pile locale. Si cela n'était 
pas fait, le compilateur ne toucherait pas ces registres, et ca serait un environnement 
trop étroit pour l'allocateur de registres du compilateur. 


Cherchons ce morceau de code: 


Listing 1.271 : do filp open() (noyau Linux 2.6.31) 


1426hse.de/uwe/articles/gcc-attributes.html#func-regparm 
143kernelnewbies.org/Linux_2 6 20#head-042c62f290834eb1fe0a1942bbf5bb9a4acchcaf 
1^^yoir aussi le fichier arch/x86/include/asm/calling.h dans l'arborescence du noyau 
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loc COIEF684: ; CODE XREF: do filp open+4F 
test bl, 40h ; 0 CREAT 
jnz loc COIEF810 
mov edi, ebx 
shr edi, 11h 
xor edi, 1 
and edi, 1 
test ebx, 10000h 
jz short loc COIEF6D3 
or edi, 2 


0x40—c'est ce à quoi est égale la macro 0 CREAT. Le bit 0x40 de open flag est 
testé, et si il est à 1, le saut de l'instruction JNZ suivante est effectué. 


ARM 
Le bit 0 CREAT est testé différemment dans le noyau Linux 3.8.0. 


Listing 1.272 : noyau Linux 3.8.0 


struct file *do filp open(int dfd, struct filename *pathname, 
const struct open flags *op) 
1 
filp = path_openat(dfd, pathname, ánd, op, flags | LOOKUP_RCU); 
} 
static struct file *path openat(int dfd, struct filename *pathname, 


struct nameidata *nd, const struct open flags *op, int 7 
S flags) 


error = do last(nd, &path, file, op, &opened, pathname); 


static int do last(struct nameidata *nd, struct path *path, 
struct file *file, const struct open flags *op, 
int *opened, struct filename *name) 
if (!(open flag € O CREAT)) { 
error = lookup fast(nd, path, &inode); 
) else { 


error = complete walk(nd); 
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Voici à quoi ressemble le noyau compilé pour le mode ARM dans IDA : 


Listing 1.273 : do last() dans vmlinux (IDA) 


.text:C0169EA8 MOV R9, R3 ; R3 - (4th argument) open flag 
.text:C0169EDA LDR R6, [R9] ; R6 - open flag 
.text:C0169F68 TST R6, 40x40 ; jumptable C0169F00 default case 
.text:C0169F6C BNE loc C016A128 

.text:C0169F70 LDR R2, [R4,#0x10] 

.text:C0169F74 ADD R12, R4, #8 

.text:C0169F78 LDR R3, [R4,#0xC] 

.text:C0169F7C MOV RO, R4 

.text:C0169F80 STR R12, [R11,#var 50] 
.text:C0169F84 LDRB R3, [R2,R3] 

.text:C0169F88 MOV R2, R8 

.text:C0169F8C CMP R3, #0 

.text:C0169F90 ORRNE R1, R1, #3 

. text: C0169F94 STRNE R1, [R4,#0x24] 

. text: C0169F98 ANDS R3, R6, #0x200000 

. text: CO169F9C MOV R1, R12 

. text: CO169FAO LDRNE R3, [R4,#0x24] 

.text:C0169FA4 ANDNE R3, R3, #1 

.text:C0169FA8 EORNE R3, R3, #1 

.text:C0169FAC STR R3, [R11,#var 54] 
.text:C0169FBO SUB R3, R11, £-var 38 
.text:C0169FB4 BL lookup fast 

.text:C016A128 loc C016A128 ; CODE XREF: do last.isra.14+DC 
.text:C016A128 MOV RO, R4 


.text:C016A12C BL complete walk 


TST est analogue à l'instruction TEST en x86. Nous pouvons «pointer » visuellement 
ce morceau de code grace au fait que la fonction Lookup fast() doit être exécutée 
dans un cas et complete walk() dans l'autre. Ceci correspond au code source de la 
fonction do last(). La macro 0 CREAT vaut 0x40 ici aussi. 


1.28.2 Mettre (à 1) et effacer (à O) des bits spécifiques 


Par exemple: 


#include <stdio.h> 


#define IS SET(flag, bit) ((flag) € (bit) ) 
#define SET BIT(var, bit) ((var) |» (bit) ) 
#define REMOVE BIT(var, bit) ((var) & ~(bit)) 
int f(int a) 

{ 


int rt=a; 
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SET BIT (rt, 0x4000); 
REMOVE BIT (rt, 0x200); 


return rt; 


}; 
int main() 


f (0x12340678) ; 
}; 


x86 


MSVC sans optimisation 


Nous obtenons (MSVC 2010) : 
Listing 1.274 : MSVC 2010 


_rt$ = -4 : size = 4 
_a$ = 8 ; Size = 4 
_f PROC 

push ebp 

mov ebp, esp 

push ecx 


mov eax, DWORD PTR a$[ebp] 

mov DWORD PTR rt$[ebp], eax 

mov ecx, DWORD PTR rt$[ebp] 

or ecx, 16384 ; 00004000H 
mov DWORD PTR rt$[ebp], ecx 

mov edx, DWORD PTR rt$[ebp] 

and edx, -513 ; fffffdffH 
mov DWORD PTR rt$[ebp], edx 

mov eax, DWORD PTR rt$[ebp] 


mov esp, ebp 
pop ebp 
ret 0 

f ENDP 


L'instruction OR met un bit à la valeur 1 tout en ignorant les autres bits. 


AND annule un bit. On peut dire que AND copie simplement tous les bits sauf un. En 
effet, dans le second opérande du AND seuls les bits qui doivent étre sauvés sont 
mis (à 1), seul celui qu'on ne veut pas copier ne l'est pas (il est à O dans le bitmask). 
C'est la maniére la plus facile de mémoriser la logique. 
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OllyDbg 


Essayons cet exemple dans OllyDbg. 
Tout d'abord, regardons la forme binaire de la constante que nous allons utiliser: 


0x200 (0b00000000000000000001000000000) (i.e., le 10ème bit (en comptant de- 
puis le ler)). 


0x200 inversé est OxFFFFFDFF (0011111111111111111110111111111). 
0x4000 (0b00000000000000100000000000000) (i.e., le 15ème bit). 


La valeur d'entrée est: 0x12340678 (0b10010001101000000011001111000). Nous 
voyons comment elle est chargée: 


CPU - main thread, module set reset Mf x! 
PUSH EBP i 
MOU EBP,ESP 
PUSH ECX 
mou EE DWORD PTR SS: CARG.1] 
MOY DI WORD PTR SS: [LOCAL.1],EAX 
MOU ECX, DWORD PTR SS: CLOCAL. 11 
| OR ECH, 60004008 
MOU DWORD PTR SS: [LOCAL.1],ECX 
EDX, DWORD PTR SS: [LOCAL. 13 
EDX,FFFFFDFF 
DWORD PTR SS:LLOCRL.11,EDX 


EAX, DWORD PTR SS:LLOCRL.12 o 
U ESP’ EBP O(FFFFFFFF) 


Bt FFFFFFFF) 
at FFFFFFFF) 
atFFFFFFFF) 
7EFDDG@GG( FFF) 
atFFFFFFFF) 


DOHANNDDO M mm 


Err ERROR. SI 
46 (NO,NB,E,BE,NS,PE,GE, m 


RETURN from set. 


RETURN from set. 
ASCII "phNJ1" 


a m 


Fig. 1.94: OllyDbg : valeur chargée dans ECX 


OR exécuté: 


CPU - main threa ule set_reset 


2] 
a 
8 
9 
8 
a 


zt 42 
ECX=12344678 
Stack [M02FFC3881=12340678 


PUSH _EBP 
MDU EBP,ESP 
PUSH _ECK 
MOU EAX, DWORD PTR SS: CARG. 11 
MOU DWORD PTR SS: LOCAL. 11, EAX 
MOU ECX, DWORD PTR SS: LOCAL. 11 
OR ECX, 60904000 

Mow PTR SS: (LOCAL. 12, ECX 
MOU EDX, DWORD PTR SS: LOCAL. 11 
AND EDX, FFFFFOFF 

MOU DWORD PTR SS:CLOCAL.1],EDx 
MOU EAX, DWORD PTR $S:CLOCAL. 11 
MOU ESP, EBP 

POP EBP 

RETN 


G bE 
H(1 hN] 


0 
6 
ø 
B 


' BBES1813 
ES 


m 
hu © 
© TT 


OOHNNDTO 


Fig. 1.95: OllyDbg : OR exécuté 


;.U0 013 
(FFFFFFFF) 


t BLFFFFFFFF) 
it B(FFFFFFFF) 
t BLFFFFFFFF) 
it 7EFDDOGO(FFF) 
it B(FFFFFFFF) 


RETURN from set. 


RETURN from set, 
ASCII "pN21" 


Le 15éme bit est mis: 0x12344678 (0b10010001101000100011001111000). 
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La valeur est encore rechargée (car le compilateur n'est pas en mode avec optimi- 
sation) : 


CPU - main thread, module set_reset 


PUSH_EBP 
MOY EBP, ESP 
PUSH ECX 

MOV EAX, DWORD PTR SS: CARG. 11 
MOU DWORD PTR SS: CLOCAL.1],EAx 
MOV ECX, DWORD PTR SS: [LOCAL. 1] 
OR ECX, 00004000 

MOU DWORD PTR SS: [LOCAL.1],ECX 
ng EDX, DWORD PTR SS:tLOCRL.11 


f 
MOU DWORD PTR SS:CLOCAL. 11, EDX 
MOU EAX, DWORD PTR 35: LOCAL. 11 
MOU ESP, EBP 

POP EBP 

RETN 


00E31019 


it B(FFFFFFFF) 

t BLFFFFFFFF) 

t BLFFFFFFFF) 

it B(FFFFFFFF) 
7EFDDaBatFFF) 

it B(FFFFFFFF) 


m 
= 
T 


a 


Inn-FFFFFDFF 
EDX=12344678 


P4 
AD 
zu 
Sø 
TO 
DO 
08 


— ANS 
ar 8 de | RETURN from set, 


HCI ANI 
RETURN from set. 


II "pN1" 


Fig. 1.96: OllyDbg : valeur rechargée dans EDX 
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AND exécuté: 


CPU - main thread, module set 


13 


PUSH EEP 
MOU EBP,ESP 
MOU ERS DWORD PTR SS: LARG. 11 

; un 
MOU DWORD PTR SS: LOCAL. 11,ERX EFL 
MOU ECX, DWORD PTR SS: LLOCRL. 11 : 
OR ECX, Baam4ana 
MOU DUORD PTR SS:LLOCRL.11,ECX 
MOU EDX, DWORD PTR SS: LOCAL. 11 
AND EDX, FFFFFOFF 
MOU DWORD PTR SS:LLOCRL.11,EDX 
MOU EAX, DWORD PTR SS:CLOCAL. 1] 
MOU ESP, EBP 
POP EBP 
RETN 


minm 


m mmmm 


IP B0E3161 reset. BBE31B1F 
C E jit B(FFFFFFFF) 
jit BLFFFFFFFF) 
jit B(FFFFFFFF) 
jit B(FFFFFFFF) 

jit TEFDDGGB(FFF) 
2bit B(FFFFFFFF) 


E 
EDX-12344478 
Stack [0B2FFC881=12344678 


)jO-nmDT00 


M m c 
m 
Nr 


is i 22122 D pep 002 7 y | RETURN from set. 


HCI ANI 


RETURN from set, 
ASCII "pN1" 


Fig. 1.97: OllyDbg : AND exécuté 


Le 10ème bit a été mis à 0 (ou, en d'autres mots, tous les bits ont été laissés sauf le 
10ème) et la valeur finale est maintenant 0x12344478 (0b10010001101000100010001111000). 


MSVC avec optimisation 


Si nous le compilons dans MSVC avec l'option d'optimisation (/0x), le code est méme 
plus court: 


Listing 1.275 : MSVC avec optimisation 


_a$ = 8 : size = 4 
f PROC 
mov eax, DWORD PTR _a$[esp-4] 
and eax, -513 ; fffffdffH 
or eax, 16384 ; 00004000H 
ret 0 
E: ENDP 


GCC sans optimisation 


Essayons avec GCC 4.4.1 sans optimisation: 


Listing 1.276 : GCC sans optimisation 


public f 
f proc near 
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var_4 = dword ptr -4 

arg_0 = dword ptr 8 
push ebp 
mov ebp, esp 
sub esp, 10h 
mov eax, [ebp+arg 0] 
mov [ebp+var_4], eax 
or [ebp+var_4], 4000h 
and [ebp+var_4], OFFFFFDFFh 
mov eax, [ebp+var 4] 
leave 
retn 

f endp 


Il y a du code redondant, toutefois, c'est plus court que la version MSVC sans opti- 
misation. 
Maintenant, essayons GCC avec l'option d'optimisation -03 : 


GCC avec optimisation 


Listing 1.277 : GCC avec optimisation 


public f 

f proc near 

arg_0 = dword ptr 8 
push ebp 
mov ebp, esp 
mov eax, [ebp+arg 0] 
pop ebp 
or ah, 40h 
and ah, OFDh 
retn 

f endp 


C'est plus court. Il est intéressant de noter que le compilateur travaille avec une 
partie du registre EAX via le registre AH—qui est la partie du registre EAX située entre 
les 8ème et 15ème bits inclus. 


Octet d'indice 
716 5413/1211 0 
RAX* 


AH | AL 


N.B. L'accumulateur du CPU 16-bit 8086 était appelé AX et consistait en deux moitiés 
de 8-bit—AL (octet bas) et AH (octet haut). Dans le 80386, presque tous les registres 
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ont été étendus à 32-bit, l'accumulateur a été appelé EAX, mais pour des raisons de 
compatibilité, ses anciennes parties peuvent toujours étre accédées par AX/AH/AL. 


Puisque tous les CPUs x86 sont des descendants du CPU 16-bit 8086, ces anciens 
opcodes 16-bit sont plus courts que les nouveaux sur 32-bit. C'est pourquoi l'instruc- 
tion or ah, 40h occupe seulement 3 octets. II serait plus logique de générer ici or 
eax, 04000h mais ca fait 5 octets, ou méme 6 (dans le cas ou le registre du premier 
opérande n'est pas EAX). 


GCC avec optimisation et regparm 


Il serait encore plus court en mettant le flag d'optimisation -03 et aussi regparm=3. 


Listing 1.278 : GCC avec optimisation 


public f 

f proc near 
push ebp 
or ah, 40h 
mov ebp, esp 
and ah, OFDh 
pop ebp 
retn 

f endp 


En effet, le premier argument est déjà chargé dans EAX, donc il est possible de tra- 
vailler avec directement. Il est intéressant de noter qu'à la fois le prologue (push ebp 
/ mov ebp,esp) et l'épilogue (pop ebp) de la fonction peuvent être facilement omis 
ici, mais sans doute que GCC n'est pas assez bon pour effectuer une telle optimisa- 
tion de la taille du code. Toutefois, il est préférable que de telles petites fonctions 
soient des fonctions inlined (3.14 on page 649). 


ARM + avec optimisation Keil 6/2013 (Mode ARM) 


Listing 1.279 : avec optimisation Keil 6/2013 (Mode ARM) 


02 0C CO E3 BIC RO, RO, #0x200 
01 09 80 E3 ORR RO, RO, #0x4000 
1E FF 2F El BX LR 


L'instruction BIC (Bitwise bit Clear) est une instruction pour mettre à zéro des bits 
spécifiques. Ceci est comme l'instruction AND, mais avec un opérande inversé. l.e., 
c'est analogue à la paire d'instructions NOT +AND. 


ORR est le «ou logique », analogue à OR en x86. 


Jusqu'ici, c'est facile. 


ARM + avec optimisation Keil 6/2013 (Mode Thumb) 
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Listing 1.280 : avec optimisation Keil 6/2013 (Mode Thumb) 


01 21 89 03 MOVS R1, 0x4000 

08 43 ORRS RO, R1 

49 11 ASRS R1, R1, $5 ; génére 0x200 et le met dans R1 
88 43 BICS RO, R1 

70 47 BX LR 


Il semble que Keil a décidé que le code en mode Thumb, pour générer 0x200 à partir 
de 0x4000, est plus compact que celui pour écrire 0x200 dans un registre arbitraire. 


C'est pourquoi, avec l'aide de ASRS (décalage arithmétique vers la droite), cette 
valeur est calculée comme 0x4000 > 5. 


ARM + avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Listing 1.281 : avec optimisation Xcode 4.6.3 (LIVM) (Mode ARM) 


42 0C CO E3 BIC RO, RO, #0x4200 
01 09 80 E3 ORR RO, RO, #0x4000 
1E FF 2F El BX LR 


Le code qui a été généré par LLVM, pourrait étre quelque chose comme ca sous la 
forme de code source: 


REMOVE BIT (rt, 0x4200); 
SET BIT (rt, 0x4000); 


Et c'est exactement ce dont nous avons besoin. Mais pourquoi 0x4200 ? Peut-étre 
que c'est un artefact de l'optimiseur de LLVM1#. 


Probablement une erreur de l'optimiseur du compilateur, mais le code généré fonc- 
tionne malgré tout correctement. 


Vous pouvez en savoir plus sur les anomalies de compilateur ici (11.5 on page 1291). 
avec optimisation Xcode 4.6.3 (LLVM) pour le mode Thumb génére le méme code. 


ARM: plus d'informations sur l'instruction BIC 


Retravaillons légérement l'exemple: 


int f(int a) 


1 
int rt=a; 
REMOVE BIT (rt, 0x1234); 
return rt; 

}; 


Ensuite Keil 5.03 pour mode ARM avec optimisation fait: 


145 C'était LLVM build 2410.2.00 fourni avec Apple Xcode 4.6.3 
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f PROC 
BIC ro0,r0,*0x1000 
BIC ro, r0,#0x234 
BX lr 
ENDP 


Il y a deux instructions BIC, i.e., les bits 0x1234 sont mis à zéro en deux temps. 


C'est parce qu'il n'est pas possible d'encoder 0x1234 dans une instruction BIC, mais 
il est possible d'encoder 0x1000 et 0x234. 
ARM64: GCC (Linaro) 4.9 avec optimisation 


GCC en compilant avec optimisation pour ARM64 peut utiliser l'instruction AND au 
lieu de BIC: 


Listing 1.282 : GCC (Linaro) 4.9 avec optimisation 


f: 
and w0, w0, -513 ; OxFFFFFFFFFFFFFDFF 
orr w0, w0, 16384 ; 0x4000 
ret 


ARM64: GCC (Linaro) 4.9 sans optimisation 


GCC sans optimisation génère plus de code redondant, mais fonctionne comme celui 
optimisé: 


Listing 1.283 : GCC (Linaro) 4.9 sans optimisation 


f: 
sub Sp, Sp, #32 
str w0, [sp,12] 
ldr w0, [sp,12] 
str w0, [sp,28] 
ldr w0, [sp,28] 
orr w0, w0, 16384 ; 0x4000 
str w0, [sp,28] 
ldr w0, [sp,28] 
and w0, w0, -513 ; OxFFFFFFFFFFFFFDFF 
str w0, [sp,28] 
ldr w0, [sp,28] 
add sp, Sp, 32 
ret 
MIPS 
Listing 1.284 : GCC 4.4.5 avec optimisation (IDA) 
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ori $a0, 0x4000 
; $a0-a|0x4000 
li $v0, OxFFFFFDFF 
jr $ra 
and $v0, $a0, $v0 


; à la fin: $v0 = $80 € $v0 = aj0x4000 € OxFFFFFDFF 


ORI est, bien sûr, l'opération OR. «I» dans l'instruction signifie que la valeur est 
intégrée dans le code machine. 


Mais aprés ça, nous avons AND. Il n'y a pas moyen d'utiliser ANDI car il n'est pas 
possible d'intégrer le nombre OxFFFFFDFF dans une seule instruction, donc le com- 
pilateur doit d'abord charger OxFFFFFDFF dans le registre $VO et ensuite génére AND 
qui prend toutes ses valeurs depuis des registres. 


1.28.3 Décalages 


Les décalages de bit sont implémentés en C/C++ avec les opérateurs « et >. Le x86 
ISA possede les instructions SHL (SHift Left / décalage à gauche) et SHR (SHift Right 
/ décalage à droite) pour ceci. Les instructions de décalage sont souvent utilisées 
pour la division et la multiplication par des puissances de deux: 2” (e.g., 1, 2, 4, 8, 
etc.) : 1.24.1 on page 278, 1.24.2 on page 284. 


Les opérations de décalage sont aussi si importantes car elles sont souvent utilisées 
pour isoler des bits spécifiques ou pour construire une valeur à partir de plusieurs 
bits épars. 


1.28.4 Mettre et effacer des bits spécifiques: exemple avec 
le FPU 


Voici comment les bits sont organisés dans le type float au format IEEE 754: 


3130 2322 0 


S| exposant mantisse ou fraction 


( S — signe ) 


Le signe du nombre est dans le MSB?**. Est-ce qu'il est possible de changer le signe 
d'un nombre en virgule flottante sans aucune instruction FPU? 


#include <stdio.h> 


float my_abs (float i) 


{ 
unsigned int tmp=(*(unsigned int*)&i) € Ox7FFFFFFF; 
return *(float*)&tmp; 


}; 


float set sign (float i) 


146Bit le plus significatif 
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1 
unsigned int tmp=(*(unsigned int*)&i) | 0x80000000; 
return *(float*)&tmp; 

$; 

float negate (float i) 

1 
unsigned int tmp=(*(unsigned int*)&i) ^ 0x80000000; 
return *(float*)&tmp; 

Hh 

int main() 

1 
printf ("my _abs():\n"); 
printf ("%f\n", my abs (123.456)); 
printf ("%f\n", my abs (-456.123)); 
printf ("set _sign():1n"); 
printf ("%f\n", set sign (123.456)); 
printf ("%f\n", set sign (-456.123)); 
printf ("negate():\n"); 
printf ("sfin", negate (123.456)); 
printf ("%f\n", negate (-456.123)); 

$; 


Nous avons besoin de cette ruse en C/C++ pour copier vers/depuis des valeurs 
float sans conversion effective. Donc il y a trois fonctions: my abs() supprime MSB; 
set sign() met MSB et negate() l'inverse. 


XOR peut étre utilisé pour inverser un bit. 


x86 
Le code est assez simple. 


Listing 1.285 : MSVC 2012 avec optimisation 


_tmp$ = 8 

_ig = 8 

_my_abs PROC 
and DWORD PTR i$[esp-4], 2147483647 ; 7fffffffH 
fld DWORD PTR _tmp$[esp-4] 
ret 0 

_my_abs ENDP 

_tmp$ = 8 

_ig = 8 

_set_sign PROC 
Sr DWORD PTR _i$[esp-4], -2147483648 ; 80000000H 
fld DWORD PTR _tmp$[esp-4] 
ret 0 


set sign ENDP 
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negate PROC 


xor DWORD PTR i$[esp-4], -2147483648 ; 30000000H 
fld DWORD PTR tmp$[esp-4] 
ret 0 


negate ENDP 


Une valeur en entrée de type float est prise sur la pile, mais traitée comme une 
valeur entiére. 


AND et OR supprime et mette le bit désiré. XOR l'inverse. 


Enfin, la valeur modifiée est chargée dans STO,car les nombres en virgule flottante 
sont renvoyés dans ce registre. 


Maintenant essayons l'optimisation de MSVC 2012 pour x64: 
Listing 1.286 : MSVC 2012 x64 avec optimisation 


tmp$ = 8 

i$ = 8 

my abs PROC 
movss DWORD PTR [rsp+8], xmmO 
mov eax, DWORD PTR i$[rsp] 
btr eax, 31 
mov DWORD PTR tmp$[rsp], eax 
movss xmm0, DWORD PTR tmp$[rsp] 
ret 0 

my abs ENDP 

TEXT ENDS 

tmp$ = 8 

ig = 8 


set_sign PROC 
movss DWORD PTR [rsp+8], xmm0 


mov eax, DWORD PTR i$[rsp] 
bts eax, 31 

mov DWORD PTR tmp$[rsp], eax 
movss xmm0, DWORD PTR tmp$[rsp] 
ret 0 


set_sign ENDP 


tmp$ = 8 
ig = 8 
negate PROC 
movss DWORD PTR [rsp+8], xmm0 


mov eax, DWORD PTR i$[rsp] 
btc eax, 31 

mov DWORD PTR tmp$[rsp], eax 
movss xmm0, DWORD PTR tmp$[rsp] 
ret 0 


negate ENDP 


La valeur en entrée est passée dans XMMO, puis elle est copiée sur la pile locale et 
nous voyons des nouvelles instructions: BTR, BTS, BTC. 
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Ces instructions sont utilisées pour effacer (BTR), mettre (BTS) et inverser (ou faire 
le complément: BTC) de bits spécifiques. Le bit d'index 31 est le MSB, en comptant 
depuis 0. 


Enfin, le résultat est copié dans XMMO, car les valeurs en virgule flottante sont ren- 
voyées dans XMMO en environnement Win64. 


MIPS 
GCC 4.4.5 pour MIPS fait essentiellement la méme chose: 


Listing 1.287 : GCC 4.4.5 avec optimisation (IDA) 


my abs: 
; déplacer depuis le coprocesseur 1: 
mfcl $v1, $f12 
li $vO, Ox7FFFFFFF 
; $v0=0x7FFFFFFF 
; faire AND: 
and $vO, $v1 
; déplacer vers le coprocesseur 1: 
mtcl $vO, $f0 
; return 
jr $ra 
or $at, $zero ; slot de délai de branchement 


set sign: 
; déplacer depuis le coprocesseur 1: 
mfcl $v0, $f12 
lui $v1, 0x8000 
; $v1=0x80000000 
; faire OR: 
or $vO, $vl, $v0 
; déplacer vers le coprocesseur 1: 
mtcl $vO, $f0 
; return 
jr $ra 
or $at, $zero ; slot de délai de branchement 


negate: 
; déplacer depuis le coprocesseur 1: 
mfcl $v0, $f12 
lui $v1, 0x8000 
; $v1=0x80000000 
; do XOR: 
xor $vO, $vl, $v0 
; déplacer vers le coprocesseur 1: 
mtcl $vO, $f0 
; Sortir 
jr $ra 
or $at, $zero ; slot de délai de branchement 


Une seule instruction LUI est utilisée pour charger 0x80000000 dans un registre, car 
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LUI efface les 16 bits bas et ils sont à zéro dans la constante, donc un LUI sans ORI 
ultérieur est suffisant. 


ARM 
avec optimisation Keil 6/2013 (Mode ARM) 


Listing 1.288 : avec optimisation Keil 6/2013 (Mode ARM) 


my abs PROC 

; effacer bit: 
BIC ro, r0,#0x80000000 
BX lr 


set sign PROC 

; faire OR: 
ORR rO, r0,#0x80000000 
BX lr 


negate PROC 

; faire XOR: 
EOR r0,r0,*0x80000000 
BX lr 


Jusqu'ici tout va bien. 
ARM a l'instruction BIC, qui efface explicitement un (des) bit(s) spécifique(s). EOR 
est le nom de l'instruction ARM pour XOR («Exclusive OR / OU exclusif »). 


avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.289 : avec optimisation Keil 6/2013 (Mode Thumb) 


my abs PROC 

LSLS r0,r0,#1 
; rQ=i<<1 

LSRS r0,r0,#1 
; rQ=(i<<1)>>1 

BX lr 

ENDP 
set sign PROC 

MOVS r1,#1 
= rl=t 

LSLS r1,r1,*31 
; r1=1<<31=0x80000000 

ORRS ro,ro, rl 


; rO-rO | 0x80000000 
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BX lr 

ENDP 
negate PROC 

MOVS r1,41 
» Fil 

LSLS r1,r1,*31 
; r1=1<<31=0x80000000 

EORS ro,ro,rl 
; rO-rO ^ 0x80000000 

BX lr 

ENDP 


En ARM, le mode Thumb offre des instructions 16-bit et peu de données peuvent y 
étre encodées, donc ici une paire d'instructions MOVS/LSLS est utilisée pour former 
la constante 0x80000000. Ca fonctionne comme ceci: 1 << 31 = 0180000000. 


Le code de my_abs est bizarre et fonctionne pratiquement comme cette expression: 
(i «« 1) >> 1. Cette déclaration semble vide de sens. Mais néanmoins, lorsque input << 1 
est exécuté, le MSB (bit de signe) est simplement supprimé. Puis lorsque la déclara- 
tion suivante result »» 1 est exécutée, tous les bits sont à nouveau à leur place, mais 
le MSB vaut zéro, car tous les «nouveaux » bits apparaissant lors d'une opération de 
décalage sont toujours zéro. C'est ainsi que la paire d'instructions LSLS/LSRS efface 
le MSB. 


avec optimisation GCC 4.6.3 (Raspberry Pi, Mode ARM) 


Listing 1.290 : avec optimisation GCC 4.6.3 for Raspberry Pi (Mode ARM) 


my abs 
; copier depuis SO vers R2: 
FMRS R2, S0 
; effacer le bit: 
BIC R3, R2, #0x80000000 
; copier depuis R3 vers S0: 
FMSR S0, R3 
BX LR 


set sign 
; copier depuis SO vers R2: 
FMRS R2, SO 
; faire OR: 
ORR R3, R2, #0x80000000 
; copier depuis R3 vers S0: 
FMSR S0, R3 
BX LR 


negate 
; copier depuis SO vers R2: 
FMRS R2, SO 
; faire ADD: 
ADD R3, R2, #0x80000000 
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; copier depuis R3 vers S0: 
FMSR S0, R3 
BX LR 


Lancons Linux pour Raspberry Pi dans QEMU et ca émule un FPU ARM, dons les S- 
registres sont utilisés pour les nombres en virgule flottante au lieu des R-registres. 


L'instruction FMRS copie des données des GPR vers le FPU et retour. 


my abs() etset sign() ressemblent a ce que l'on attend, mais negate()? Pourquoi 
est-ce qu'il y a ADD au lieu de XOR? 


C'est dur à croire, mais l'instruction ADD register, 0x80000000 fonctionne tout 
comme 

XOR register, 0x80000000. Tout d'abord, quel est notre but? Le but est de chan- 
ger le MSB, donc oublions l'opération XOR. Des mathématiques niveau scolaire, nous 
nous rappelons qu'ajouter une valeur comme 1000 à une autre valeur n'affecte ja- 
mais les 3 derniers chiffres. Par exemple: 1234567 -- 10000 — 1244567 (les 4 derniers 
chiffres ne sont jamais affectés). 


Mais ici nous opérons en base décimale et 
0x80000000 est 0b100000000000000000000000000000000, i.e., seulement le bit 
le plus haut est mis. 


Ajouter 0x80000000 à n'importe quelle valeur n'affecte jamais les 31 bits les plus 
bas, mais affecte seulement le MSB. Ajouter 1 à 0 donne 1. 


Ajouter 1 à 1 donne 0b10 au format binaire, mais le bit d'indice 32 (en comptant à 
partir de zéro) est abandonné, car notre registre est large de 32 bit, donc le résultat 
est 0. C'est pourquoi XOR peut étre remplacé par ADD ici. 


Il est difficile de dire pourquoi GCC a décidé de faire ca, mais ca fonctionne correc- 
tement. 


1.28.5 Compter les bits mis à 1 


Voici un exemple simple d'une fonction qui compte le nombre de bits mis à 1 dans 
la valeur en entrée. 


Cette opération est aussi appelée «population count »!^7. 


#include <stdio.h> 
#define IS SET(flag, bit) ((flag) € (bit) ) 


int f(unsigned int a) 
{ 
int i; 
int rt=0; 
for (i=0; i<32; i++) 


if (IS_SET (a, 1<<i)) 
rtr; 


147les CPUs x86 modernes (qui supportent SSE4) ont méme une instruction POPCNT pour cela 
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return rt; 
}; 
int main() 

f(0x12345678); // test 
}; 


Dans cette boucle, la variable d'itération ¿ prend les valeurs de O à 31, donc la dé- 
claration 1 « i prend les valeurs de 1 à 0x80000000. Pour décrire cette opération 
en langage naturel, nous dirions décaler 1 par n bits à gauche. En d'autres mots, la 
déclaration 1 « i produit consécutivement toutes les positions possible pour un bit 
dans un nombre de 32-bit. Le bit libéré à droite est toujours à O. 


Voici une table de tous les 1 «i possible for i = 0...31 : 
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C/C++ expression | Puissance de deux | Forme décimale | Forme hexadécimale 
1<0 20 1 1 

1<1 oF 2 2 

1<2 27 4 4 

1<3 23 8 8 

1<4 21 16 0x10 

1«5 gs 32 0x20 

1<6 26 64 0x40 

1«7 27 128 0x80 

1<8 28 256 0x100 

1«9 29 512 0x200 

1«10 219 1024 0x400 

1< 11 24 2048 0x800 
1«12 pr 4096 0x1000 

1<« 13 ge 8192 0x2000 
1<14 ge 16384 0x4000 
1<15 ge 32768 0x8000 

1<« 16 219 65536 0x10000 
1< 17 git 131072 0x20000 
1«18 319 262144 0x40000 
1«19 219 524288 0x80000 
1< 20 ga 1048576 0x100000 
1<« 21 D 2097152 0x200000 
1« 22 qe 4194304 0x400000 

1 <« 23 gus 8388608 0x800000 
1<« 24 pe 16777216 0x1000000 
1« 25 gus 33554432 0x2000000 
1< 26 228 67108864 0x4000000 
1<« 27 227 134217728 0x8000000 
1« 28 Ja 268435456 0x10000000 
1« 29 249 536870912 0x20000000 
1« 30 2" 1073741824 0x40000000 
1<« 31 ga 2147483648 0x80000000 


Ces constantes (masques de bit) apparaissent tres souvent le code et un rétro- 
ingénieur pratiquant doit pouvoir les repérer rapidement. 


Les nombres décimaux avant 65536 et les hexadécimaux sont faciles a mémoriser. 
Tandis que les nombres décimaux aprés 65536 ne valent probablement pas la peine 


de l'étre. 


Ces constantes sont utilisées trés souvent pour mapper des flags sur des bits spé- 
cifiques. Par exemple, voici un extrait de ssl private.h du code source d'Apache 


2.4.6: 


/** 


* Define the SSL options 


ES 


#define SSL OPT NONE 


define SSL OPT RELSET (1««0) 
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#define 
#define 
#define 
#define 
#define 
#define 


SSL OPT STDENVVARS ( 
SSL OPT EXPORTCERTDATA ( 
SSL OPT FAKEBASICAUTH ( 
SSL OPT STRICTREQUIRE (1<<5 
SSL OPT OPTRENEGOTIATE ( 
SSL OPT LEGACYDNFORMAT ( 


Revenons à notre exemple. 


La macro IS SET teste la présence d'un bit dans a. 


La macro IS SET est en fait l'opération logique AND (AND) et elle renvoie O si le bit 
testé est absent (à 0), ou le masque de bit, si le bit est présent (à 1). L'opérateur 
if() en C/C++ exécute son code si l'expression n'est pas zéro, cela peut méme étre 
123456, c'est pourquoi il fonctionne toujours correctement. 


x86 
MSVC 


Compilons-le (MSVC 2010) : 


Listing 1.291 : MSVC 2010 


_rt$ = -8 ; taille = 4 
i$ = -4 ; taille = 4 
a$ = 8 ; taille = 4 
_f PROC 

push ebp 

mov ebp, esp 

sub esp, 8 

mov DWORD PTR rt$[ebp], 0 

mov DWORD PTR i$[ebp], 0 

jm SHORT $LN4@f 
$LN3@f : 

mov eax, DWORD PTR i$[ebp] 

add eax, 1 

mov DWORD PTR i$[ebp], eax 
$LN4@f : 

cmp DWORD PTR i$[ebp], 32 

jge SHORT $LN2@f 

mov edx, 1 

mov ecx, DWORD PTR i$[ebp] 

shl edx, cl 

and edx, DWORD PTR a$[ebp] 

je SHORT $LN1@f 

0? 

suivantes 

mov eax, DWORD PTR rt$[ebp] 

add eax, 1 

mov DWORD PTR rt$[ebp], eax 
$LN1@f : 


jmp 


SHORT $LN3@f 


; incrémenter i 


; 00000020H 
; boucle terminée? 


; EDX=EDX<<CL 


résultat de L'instruction AND égal a 


; alors passer les instructions 


; non, différent de zéro 
; incrémenter rt 
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$LN2Gf : 
mov 
mov 
pop 
ret 

f  ENDP 


eax, DWORD PTR rt$[ebp] 
esp, ebp 

ebp 

0 
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OllyDbg 


Chargeons cet exemple dans OllyDbg. Définissons la valeur d'entrée a 0x12345678. 


Pour i = 1, nous voyons comment i est chargé dans ECX : 


CPU - main thread, module shifts 


< 


JMP SHORT G029101F 
MOU EAX, rie PTR SS:CLOCAL. 1] 


EAX 

DUO PTR SS: LOCAL. 1], EAX 
8370 FC 20 DWORD PTR SS: [LOCAL.11,20 
7D 1A SHORT 06029103F 
BA 61698800 EDX, 1 
8B4D FC ECX, DWORD PTR SS:CLOCAL. 11 
EDX, CL 


AND EDX, DWORD PTR SS: CARG.1] 
Ye SHORT 00291030 


- EAS 


it vEFDDBaBtFFF) 
jit G(FFFFFFFF) 


C 
P 
A 
Z 
E 
D 


OOK ae 


EDX-1 
Loop 88291816: loop variable CLOCAL.11](+1) 


RETURN from 


RETURN from 
ASCII "pho" 


Fig. 1.98: OllyDbg : i = 1, i est chargé dans ECX 


EDX contient 1. SHL va étre exécuté maintenant. 
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SHL a été exécuté: 


83EC 68 SUB ESP,8 

C745 FS ooga MOU DWORD PTR SS: [LOCAL.21,8 
Ens FC 66601 MOU DWORD PTR $8: ELOCAL. 11, a 
JMP SHORT 662916 

MoU ERK, D » DWORD PTR SS: CLOCAL. 1] 


DUGRD PTR SS: ELOCRL. 11, ERX 
837D FC 28 DWORD PTR_SS:CLOCAL. 11,28 


70 1A SHORT 6029103F = 
BA 91088000 EDX, 1 

8B4D FC ECH, DUORD PTR SS: CLOCAL. 13 8029102F shifts. 00293102F 
MESA - She Dx, CL PTR SS:CARG.1] ES 002B 32bit G(FFFFFFFF) 
74 09 Jz SHORT 99291030 DIS OECEEEECEES 
8845 FS HOU EAX, DWORD PTR SS: CLOCAL. 21 E 


it PEFDDOGOLEFF) 
LY aun J 
Stack Taolarsed i= "12548078 32bit G(FFFFFFFF) 

Loop 68291916: loop variable CLOCAL.1](+1) 


Miras as 
q 


i 


F 
3 
5 
A 
D 
3 
4 


CDAONDIO 
DOI 
NNO 


)8 90000000 ERROR SUCCESS 
EFL 0000292 ( Cho NB, NE, A, NS, PO, GE, G) 


RETURN from shi 


00000 


RETURN from shi 


^ ASCII "phó" 
a 00 HA 00 E 


Fig. 1.99: OllyDbg : i= 1, EDX =1 « 1 = 2 


EDX contient 1 « 1 (ou 2). Ceci est un masque de bit. 
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AND met ZF a 1, ce qui implique que la valeur en entrée (0x12345678) ANDée avec 
2 donne O: 


,ü 
MOU DWORD PTR ss ELOCAL. 11,8 
JMP SHORT 002910 
Moy ERN. D » DWORD PTR SS: CLOCAL. 11 


DURO PTR SS: ELOCRL. 11, ERX 
Eco FC 28 DWORD PTR SS: CLOCAL.11,26 
SHORT 0029103F 


EDX, 1 
ED DWORD PTR $S:CLOCAL.1] 


D EDX,DWORD PTR SS:IRRG.11 Ot FFFFFFFF) 


Je 00291030 TE | 
MOU EAX, DWORD PTR SS: LOCAL. 21 t DIEFEEEPEES 


ADD EAX, 1 @(FFFFFFFF) 
dL E 7EFODG@G(FFF) 


E r=0029103D - jumps to shift PEEFEEFEERJ 
Loop 882918016: loop variable [LOCAL. 1 astErr Ø Ø ERROR CCESS 


S,PE,GE,LE) Y 


gens 


ooo 
veev 


oc 
< 


én 61808080 
8B4D 


nu... 
< 


¿Mu 
e 


RETURN from shi 


DO 
oor 


RETURN from shi 
ASCII "pNa” 


DDD: 
oc 


Fig. 1.100: OllyDbg : i = 1, y a-t-il ce bit dans la valeur en entrée? Non. (ZF =1) 


Donc, il n'y a pas le bit correspondant dans la valeur en entrée. 


Le morceau de code, qui incrémente le compteur ne va pas étre exécuté: l'instruction 
JZ l'évite. 
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Avancons un peu plus et i vaut maintenant 4. SHL va étre exécuté maintenant: 


CPU - main threa dule shifts (Of x! 


900 


E 


JMP SHORT 6629161F 
o ERY: DWORD PTR SS: [LOCAL. 1] 


ADD EAX, 

MOU DWORD PTR $S:CLOCAL.1],EAx 
8370 FC 20 CMP DWORD PTR SS: [LOCAL.11,20 
7D 1A JGE SHORT 0029103F 
BA 91600666 || MOU EDX, 1 60291020 
8B4D FC MOU ECX, DWORD PTR SS: [LOCAL. 1] 


SHL » CL 

AND EDX, DWORD PTR SS: [ARG. 1] 
Je SHORT 00291030 

WW ELS 


papa ad 
vtt 
GocOOOGOG| 


G OER 
< 

m 

mu 


¿ 


ERROR_SUCCESS 
NE,BE,S,PE,L,LE) 


Gr gogmaooo 


o. 


(Q ANO. 3i 850] 19) |RETURM from shi 


RETURN from shi 
ASCII "PNG" 


Fig. 1.101: OllyDbg : i — 4, i est chargée dans ECX 
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EDX =1 < 4 (ou 0x10 ou 16) : 


main thread, module shifts 


SSEC 88 SUB ESP,8 
C745 F8 00001 NOV DWORD PTR SS:CLOCAL.21,4 
C745 FC 60001 MOU DWORD PTR SS:CLOCAL. 11,4 
JMP SHORT 6629161F 
MOU EAX, DWORD PTR SS: [LOCAL. 1] 


EAX, 1 
DWORD PTR SS: LOCAL. 1], EAX 
837D FC 28 DWORD PTR SS: [LOCAL.1],20 


70 14 
BA 91690000 
SB4D FC 


a TEE 


€ 


SHORT 8829103F 
ECX; DWORD PTR SS:LLOCRL. 11 EIP 0029102F 
,DWORD PTR SS: LARG. 1] 


AND 
Je SHORT 88291930 
8B45 F8 MOU EAX, DWORD PTR SS: [LOCAL. 2] 


it B(FFFFFFFF) 

t BLFFFFFFFF) 

it B(FFFFFFFF) 

2bit B(FFFFFFFF) 
t vEFDDBBBLFFF) 

t B(FFFFFFFF) 


LastErr 00000000 ERROR SU 
EFL 000090202 (NO,NB,NE, A, 


"X 


a a ad 200 H 

Stack [0014F984]=12345678 

EDX=00000010 

Loop 60291016: loop variable CLOCAL.11(+1) 


IDANNDDO 


8 CH ; 21 A 
H(G hNG | : RETURN from shi 


RETURN from shi 
ASCII "pna”’ 


Fig. 1.102: OllyDbg : ¿=4, EDX 21 « 4 = 0x10 


Ceci est un autre masque de bit. 
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AND est exécuté: 


CPU - main thread, module shifts -{0/ xl 


C745 FS BOO MOU DWORD PTR SS:ILOCRL.21,8 
MOU DWORD PTR SS: [LOCAL.11,0 

JMP SHORT 0029101F 

MOU EAX, DWORD PTR SS:CLOCAL. 11 

ADD EAX, 1 

MOU DWORD PTR SS:ELOCRL.11,ERX 

8370 FC 20 |PCMP DWORD PTR SS:CLOCAL. 11,26 

70 1A JGE SHORT 00239103F 

BA Gigaaeea || MOU EDX 

8B4D FC HOU EC, Buono PTR 55: (LOCAL. 11 

AND EDX; DWORD PTR SS: CARG. 1] BLFFFFFFFF) 

Je 00291030 Gt FFFFFFFF) 

MOU EAX, DWORD PTR SS: LOCAL. 21 GL EEEFFEFE) 


n: ERA, 1 BLFFFFFFFF) 


7EFODGG6( FFF) 
B(FFFFFFFF) 


< 


vtt; 


"i 


a 


5 83D - jumps to shift 
Loop 88291816: loop variable [LOCAL. 1 


00202 (NO,NB,NE,A 


jme 


RETURN from shi 


RETURN from shi 


ASCII "phó" 


EN 


Fig. 1.103: OllyDbg : i = 4, y a-t-il ce bit dans la valeur en entrée? Oui. (ZF =0) 


ZF est à O car ce bit est présent dans la valeur en entrée. 
En effet, 0x12345678 & 0x10 - 0x10. 


Ce bit compte: le saut n'est pas effectué et le compteur de bit est incrémenté. 


La fonction renvoie 13. C'est le nombre total de bits à 1 dans 0x12345678. 
GCC 


Compilons-le avec GCC 4.4.1: 
Listing 1.292 : GCC 4.4.1 


public f 
f proc near 
rt = dword ptr -0Ch 
i - dword ptr -8 
arg 0 - dword ptr 8 
push ebp 
mov ebp, esp 
push ebx 
sub esp, 10h 
mov [ebp+rt], 
mov [ebp+i], 
jmp short loc_80483EF 


loc_80483D0: 
mov eax, [ebp+i] 
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mov edx, 1 
mov ebx, edx 
mov ecx, eax 
shl ebx, cl 
mov eax, ebx 
and eax, [ebp+arg 0] 
test eax, eax 
jz short loc 80483EB 
add [ebp+rt], 1 
loc 80483EB: 
add [ebpt+i], 1 
loc 80483EF: 
cmp [ebp+i], 1Fh 
jle short loc 80483D0 
mov eax, [ebp+rt] 
add esp, 10h 
pop ebx 
pop ebp 
retn 
f endp 


x64 


Modifions légérement l'exemple pour l'étendre à 64-bit: 


#include <stdio.h> 
#include <stdint.h> 


#define IS SET(flag, bit) ((flag) € (bit) ) 
int f(uint64 t a) 
{ 

uint64 t i; 

int rt=0; 

for (i=0; i<64; i++) 

if (IS SET (a, 1ULL<<i)) 
rtr; 
return rt; 


GCC 4.8.2 sans optimisation 


Jusqu'ici, c'est facile. 


Listing 1.293 : GCC 4.8.2 sans optimisation 


push rbp 
mov rbp, rsp 


WO Y OY U1 UnA 
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; rt=0 
; i-0 


mov QWORD PTR [rbp-24], rdi ; a 
mov DWORD PTR [rbp-12], 0 
mov QWORD PTR [rbp-8], 0 
jmp «2 
.L4: 
mov rax, QWORD PTR [rbp-8] 
mov rdx, QWORD PTR [rbp-24] 
; RAX = i, RDX =a 
mov ecx, eax 
ECX — d 
shr rdx, cl 
; RDX = RDX>>CL = a>>i 
mov rax, rdx 
; RAX = RDX = a>>i 
and eax, 1 
; EAX = EAX&1 = (a>>i)&1 
test rax, rax 


; est-ce que le dernier bit est zéro? 
; passer l'instruction ADD suivante, si 


je .L3 
add DWORD PTR [rbp-12], 1 
.L3: 
add QWORD PTR [rbp-8], 1 
.L2: 
cmp QWORD PTR [rbp-8], 63 
jbe .L4 
boucle, si oui 
mov eax, DWORD PTR [rbp-12] 
pop rbp 
ret 


c'est le cas. 
> rte 
; i++ 


; 1<63? 
; sauter au début du corps de la 


; renvoyer rt 


GCC 4.8.2 avec optimisation 


Listing 1.294 : GCC 4.8.2 avec optimisation 

f: 

xor eax, eax ; la variable rt sera dans le registre EAX 

xor ecx, ecx ; la variable i sera dans le registre ECX 
.L3: 

mov rsi, rdi ; charger la valeur en entrée 

lea edx, [rax+1] ; EDX=EAX+1 
; ici EDX est la nouvelle version de rt, 


; qui sera écrite dans la variable rt, si le dernier bit est à 1 


shr rsi, cl 
and esi, 1 
; est-ce que le dernier bit est 
dans EAX 

cmovne eax, edx 

add rex, 1 

cmp rcx, 64 

jne .L3 


rep ret 


; RSI=RSI>>CL 
; ESI-ESI&1 
1? Si oui, écrire la nouvelle version de rt 


; RCX++ 


; AKA fatret 
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Ce code est plus concis, mais a une particularité. 


Dans tous les exemples que nous avons vu jusqu'ici, nous incrémentions la valeur 
de «rt» apres la comparaison d'un bit spécifique, mais le code ici incrémente «rt » 
avant (ligne 6), écrivant la nouvelle valeur dans le registre EDX. Donc, si le dernier 
bit est à 1, l'instruction CMOVNE*% (qui est un synonyme pour CMOVNZ!^?) commits 
la nouvelle valeur de «rt» en déplaçant EDX («valeur proposée de rt») dans EAX («rt 
courant » qui va étre retourné à la fin). 


C'est pourquoi l'incrémentation est effectuée à chaque étape de la boucle, i.e., 64 
fois, sans relation avec la valeur en entrée. 


L'avantage de ce code est qu'il contient seulement un saut conditionnel (à la fin 
de la boucle) au lieu de deux sauts (évitant l'incrément de la valeur de «rt» et à la 
fin de la boucle). Et cela doit s'exécuter plus vite sur les CPUs modernes avec des 
prédicteurs de branchement: 2.4.1 on page 589. 


La derniére instruction est REP RET (opcode F3 C3) qui est aussi appelée FATRET par 
MSVC. C'est en quelque sorte une version optimisée de RET, qu'AMD recommande de 
mettre en fin de fonction, si RET se trouve juste aprés un saut conditionnel: [Software 
Optimization Guide for AMD Family 16h Processors, (2013)p.15] 15°. 


MSVC 2010 avec optimisation 


Listing 1.295 : MSVC 2010 avec optimisation 


a$ = 8 
f PROC 
; RCX = valeur en entrée 
xor eax, eax 
mov edx, 1 
lea r8d, QWORD PTR [rax+64] 
; R8D=64 
npad 5 
$LL4@f : 
test rdx, rcx 


; il n'y a pas le méme bit dans la valeur en entrée? 
; alors passer la prochaine instruction INC. 


je SHORT $LN3Gf 

inc eax ; rte 
$LN3@f : 

rol rdx, 1 ; RDX=RDX<<1 

dec r8 ; R8-- 

jne SHORT $LL4@f 

fatret 0 
f ENDP 


148Conditional MOVe if Not Equal 
14Conditional MOVe if Not Zero 
1*0| ire aussi à ce propos: http://repzret.org/p/repzret/ 
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Ici l'instruction ROL est utilisée au lieu de SHL, qui est en fait «rotate left / pivoter 
à gauche » au lieu de «shift left / décaler à gauche », mais dans cet exemple elle 
fonctionne tout comme SHL. 


Vous pouvez en lire plus sur l'instruction de rotation ici: .1.6 on page 1342. 
R8 ici est compté de 64 à 0. C'est tout comme un i inversé. 
Voici une table de quelques registres pendant l'exécution: 


RDX R8 
0x0000000000000001 | 64 
0x0000000000000002 | 63 
0x0000000000000004 | 62 
0x0000000000000008 | 61 


0x4000000000000000 | 2 
0x8000000000000000 | 1 


À la fin, nous voyons l'instruction FATRET, qui a été expliquée ici: 1.28.5 on the pre- 
ceding page. 


MSVC 2012 avec optimisation 


Listing 1.296 : MSVC 2012 avec optimisation 


a$ = 8 
f PROC 
; RCX = valeur en entrée 
xor eax, eax 
mov edx, 1 
lea r8d, QWORD PTR [rax+32] 
; EDX = 1, R8D = 32 
npad 5 
$LL4@f : 
; pass 1 ------------------------------ 
test rdx, rcx 
je SHORT $LN3@f 
inc eax ; rt++ 
$LN3@f : 
rol rdx, 1 ; RDX=RDX<<1 
; pass 2 ------------------------------ 
test rdx, rcx 
je SHORT $LN11@f 
inc eax ; rte 
$LN11@f : 
rol rdx, 1 ; RDX=RDX<<1 
dec r8 ; R8-- 
jne SHORT $LL4@f 
fatret 0 
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MSVC 2012 avec optimisation fait presque le méme job que MSVC 2010 avec opti- 
misation, mais en quelque sorte, il génére deux corps de boucles identiques et le 
nombre de boucles est maintenant 32 au lieu de 64. 


Pour étre honnéte, il n'est pas possible de dire pourquoi. Une ruse d'optimisation? 
Peut-étre est-il meilleur pour le corps de la boucle d'étre légérement plus long? 


De toute facon, ce genre de code est pertinent ici pour montrer que parfois la sortie 
du compilateur peut étre vraiment bizarre et illogique, mais fonctionner parfaite- 
ment. 


ARM + avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


Listing 1.297 : avec optimisation Xcode 4.6.3 (LIVM) (Mode ARM) 


MOV R1, RO 

MOV RO, #0 

MOV R2, #1 

MOV R3, RO 

loc 2b54 

TST R1, R2,LSL R3 ; mettre les flags suivant R1 & 
(R2««R3) 

ADD R3, R3, #1 ; R3++ 

ADDNE RO, RO, +1 ; Si le flag ZF est mis par 0 
TST, alors RO++ 

CMP R3, #32 

BNE loc _2E54 

BX LR 


TST est la méme chose que TEST en x86. 


Comme noté précédemment (3.12.3 on page 639), il n'y a pas d'instruction de déca- 
lage séparée en mode ARM Toutefois, il y a ces modificateurs LSL (Logical Shift Left 
/ décalage logique a gauche), LSR (Logical Shift Right / décalage logique a droite), 
ASR (Arithmetic Shift Right décalage arithmétique a droite), ROR (Rotate Right / ro- 
tation a droite) et RRX (Rotate Right with Extend / rotation a droite avec extension), 
qui peuvent être ajoutés à des instructions comme MOV, TST, CMP, ADD, SUB, RSB?°?. 


Ces modificateurs définissent comment décaler le second opérande et de combien 
de bits. 


Ainsi l'instruction «TST R1, R2,LSL R3» fonctionne ici comme R1 A (R2 « R3). 


ARM + avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


Presque la méme, mais ici il y a deux instructions utilisées, LSL .W/TST, au lieu d'une 
seule TST, car en mode Thumb il n'est pas possible de définir le modificateur LSL 
directement dans TST. 


MOV R1, RO 
MOVS RO, 40 
MOV .W R9, #1 


151Ces instructions sont également appelées «instructions de traitement de données» 
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MOVS R3, 40 
loc 2F7A 

LSL.W R2, R9, R3 
TST R2, R1 
ADD .W R3, R3, 41 
IT NE 
ADDNE RO, #1 
CMP R3, 432 
BNE loc 2F7A 
BX LR 


ARM64 + GCC 4.9 avec optimisation 
Prenons un exemple en 64.bit qui a déjà été utilisé: 1.28.5 on page 424. 


Listing 1.298 : GCC (Linaro) 4.8 avec optimisation 


f: 
mov w2, 0 ; rt=0 
mov x5, 1 
mov wl, w2 
.L2: 
Isl x4, x5, x1 ; w4 = w5<<wl = 1<<i 
add w3, w2, 1 ; new rt=rt+1 
tst x4, x0 ; (1<<i) € a 
add wl, wl, 1 ; it 


; le résultat de TST était non-zéro? 

; alors w2=w3 ou rt=new rt. 

; autrement: w2=w2 ou rt=rt (opération idle) 
csel w2, w3, w2, ne 


cmp wl, 64 ; i«64? 

bne .L2 ; oui 

mov w0, w2 ; renvoyer rt 
ret 


Le résultat est très semblable à ce que GCC génère pour x64: 1.294 on page 425. 
L'instruction CSEL signifie «Conditional SELect / sélection conditionnelle ». Elle choisi 
une des deux variables en fonction des flags mis par TST et copie la valeur dans W2, 
qui contient la variable «rt ». 


ARM64 + GCC 4.9 sans optimisation 


De nouveau, nous travaillons sur un exemple 64-bit qui a déjà été utilisé: 1.28.5 on 
page 424. Le code est plus verbeux, comme d'habitude. 


Listing 1.299 : sans optimisation GCC (Linaro) 4.8 


sub sp, sp, #32 

str x0, [sp,8] ; stocker la valeur de "a" dans la zone de 
; sauvegarde des registres 

str wzr, [sp,24] ; rt-0 
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str wzr, [sp,28] ; i=0 
b .L2 
.L4: 
ldr w0, [sp,28] 
mov x1, 1 
Isl x0, x1, x0 ; X0 = X1<<X0 = 1<<i 
mov x1, x0 
; XI = dest 
ldr x0, [sp,8] 
; X0 =a 
and x0, x1, x0 


; X0 = X1&X0 = (1<<i) € a 
X0 contient zéro? alors sauter en .L3, évitant d'incrémenter "rt" 


cmp x0, xzr 
beq .L3 
; rtr 
ldr wO, [sp,24] 
add w0, wO, 1 
str w0, [sp,24] 
.L3: 
; lt 
ldr w0, [sp,28] 
add w0, w0, 1 
str w0, [sp,28] 
.L2: 


; i<=63? alors sauter en .L4 
ldr w0, [sp,28] 
cmp w0, 63 
ble .L4 

; renvoyer rt 
ldr w0, [sp,24] 
add sp, sp, 32 
ret 


MIPS 


GCC sans optimisation 


Listing 1.300 : GCC 4.4.5 sans optimisation (IDA) 


f: 
; IDA ne connaít pas le nom des variables, nous les donnons manuellement: 
rt = -0x10 
i = -0xC 
var 4 = -4 
a = 0 
addiu $sp, -0x18 
SW $fp, Ox18+var 4($sp) 
move $fp, $sp 
sw $a0, Ox18+a($fp) 


; initialiser les variables rt et i à zéro: 
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, 


sw 
sw 


b 
or 


$zero, 0x18+rt($fp) 
$zero, 0x18+i($fp) 
saut aux instructions de test de la boucle 
loc_68 


gat, 


$zero ; slot de 


loc 20: 
li 
lw 
or 
sllv 
; $v0 = 1<<i 
move 
lw 
or 
and 
; $vO = a & (1<<i) 


$v1, 
$v0, 
$at, 
$v0, 


1 
0x18+i($fp) 
$v1, $v0 


$v1, 
$vo, 
$at, 
$v0, 


$v0 
0x18+a($fp) 


$v1, $v0 


$zero ; slot de 


$zero ; slot de 


délai de branchement, NOP 


délai 


délai 


; est-ce que a € (1<<i) est égal à zéro? sauter en 


beqz 
or 


; il n'y pas eu de saut, cela signifie que a € (1<<i)!=0, il faut 


0x18+rt($fp) 
$zero ; slot de délai de chargement, 


incrémenter "rt": 
lw 


or 
addiu 
Sw 


loc 58: 

; incrémenter i: 
lw 
or 
addiu 
SW 


loc 68: 


; charger i et le comparer avec 0x20 (32). 


$vO, loc 58 
$at, $zero 


$v0, 
$at, 
$v0, 1 
$vo, 


$v0, 
$at, 
$v0, 1 

$vO, Ox18+i($fp) 


0x18+i($fp) 


0x18+rt($fp) 


; sauter en loc 20 si il vaut moins de 0x20 (32): 


lw 
or 
slti 
bnez 
or 


; épilogue de la fonction. 


lw 
move 
lw 
addiu 
jr 
or 


$vO, Ox18+i($fp) 


gat, $zero ; slot de délai 


$vO, 0x20 # ' 
$vO, loc 20 


$at, $zero ; slot de délai 


renvoyer rt: 


$vO, 0x18+rt($fp) 

$sp, $fp ; slot de délai 
$fp, Ox18+var 4( 

$sp, Ox18 ; slot de délai 
$ra 

$at, 


de chargement, 


de chargement, 


loc 58 si oui: 


$zero ; slot de délai de chargement, 


de chargement, 


NOP 


NOP 


donc 


NOP 


NOP 


NOP 


de branchement, NOP 


de chargement 


de chargement 


$zero ; slot de délai de branchement, NOP 


C'est trés verbeux: toutes les variables locales sont situées dans la pile locale et 


rechargées à chaque fois que l'on en a besoin. 


L'instruction SLLV est «Shift Word Left Logical Variable », elle différe de SLL seule- 
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ment de ce que la valeur du décalage est encodée dans l'instruction SLL (et par 
conséquent fixée) mais SLLV lit cette valeur depuis un registre. 


GCC avec optimisation 


C'est plus concis. Il y a deux instructions de décalage au lieu d'une. Pourquoi? 


Il est possible de remplacer la premiére instruction SLLV avec une instruction de 
branchement inconditionnel qui saute directement au second SLLV. Mais cela ferait 
une autre instruction de branchement dans la fonction, et il est toujours favorable 
de s'en passer: 2.4.1 on page 589. 


Listing 1.301 : GCC 4.4.5 avec optimisation (IDA) 


f: 

; $a0=a 

; la variable rt sera dans $v0: 
move $vO, $zero 

; la variable i sera dans $v1: 
move $v1, $zero 
li $tO, 1 
li $a3, 32 


sllv $al, $tO, $v1 
; $al = $t0<<$vl = l<<i 


loc_14: 
and $al, $a0 
; $al = a&(1<<i) 
; incrémenter i: 
addiu $v1, 1 
; sauter en loc 28 si a&(1««i)--0 et incrémenter rt: 
begz $al, loc 28 
addiu $a2, $v0, 1 
; Si le saut BEQZ n'a pas été suivi, sauver la nouvelle valeur de rt dans 


$v0: 

move $v0, $a2 

loc 28: 

; Si i!-32, sauter en loc 14 et préparer la prochaine valeur décalée: 
bne $v1, $a3, loc 14 
sllv $al, $t0, $vl 

; sortir 
jr $ra 
or $at, $zero ; slot de délai de branchement, NOP 


1.28.6 Conclusion 


Semblables aux opérateurs de décalage de C/C++ « et >>, les instructions de déca- 
lage en x86 sont SHR/SHL (pour les valeurs non-signées) et SAR/SHL (pour les valeurs 
signées). 
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Les instructions de décalages en ARM sont LSR/LSL (pour les valeurs non-signées) 
et ASR/LSL (pour les valeurs signées). 


Il est aussi possible d'ajouter un suffixe de décalage à certaines instructions (qui sont 
appelées «data processing instructions/instructions de traitement de données »). 
Tester un bit spécifique (connu à l'étape de compilation) 
Tester si le bit 051000000 (0x40) est présent dans la valeur du registre: 

Listing 1.302 : C/C++ 


if (input&0x40) 


Listing 1.303 : x86 


TEST REG, 40h 
JNZ is set 
; le bit n'est pas mis (est à 0) 


Listing 1.304 : x86 


TEST REG, 40h 
JZ is cleared 
; le bit est mis (est à 1) 


Listing 1.305 : ARM (Mode ARM) 


TST REG, 40x40 
BNE is set 
; le bit n'est pas mis (est à 0) 


Parfois, AND est utilisé au lieu de TEST, mais les flags qui sont mis sont les méme. 


Tester un bit spécifique (spécifié lors de l'exécution) 


Ceci est effectué en général par ce bout de code C/C++ (décaler la valeur de n bits 
vers la droite, puis couper le plus petit bit) : 


Listing 1.306 : C/C++ 


if ((value>>n)&1) 


Ceci est en général implémenté en code x86 avec: 


Listing 1.307 : x86 


; REG=input value 
; CL=n 

SHR REG, CL 

AND REG, 1 
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Ou (décaler 1 bit n fois à gauche, isoler ce bit dans la valeur entrée et tester si ce 


n'est pas zéro) : 


Listing 1.308 : C/C++ 


if (value & (1««n)) 


Ceci est en général implémenté en code x86 avec: 


Listing 1.309 : x86 


; CL=n 

MOV REG, 1 

SHL REG, CL 

AND input value, REG 


Mettre à 1 un bit spécifique (connu à l'étape de compilation) 


Listing 1.310 : C/C++ 


value-value|0x40; 


Listing 1.311 : x86 


OR REG, 40h 


Listing 1.312 : ARM (Mode ARM) and ARM64 


ORR RO, RO, #0x40 


Mettre à 1 un bit spécifique (spécifié lors de l'exécution) 


Listing 1.313 : C/C++ 


value=value| (1<<n); 


Ceci est en général implémenté en code x86 avec: 


Listing 1.314 : x86 


; CL=n 

MOV REG, 1 

SHL REG, CL 

OR input_value, REG 
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Mettre à O un bit spécifique (connu à l'étape de compilation) 
Il suffit d'effectuer l'opération AND sur la valeur inversée: 


Listing 1.315 : C/C++ 


value=value&(-0x40 ) ; 


Listing 1.316 : x86 


AND REG, OFFFFFFBFh 


Listing 1.317 : x64 


AND REG, OFFFFFFFFFFFFFFBFh 


Ceci laisse tous les bits qui sont à 1 inchangés excepté un. 


ARM en mode ARM a l'instruction BIC, qui fonctionne comme la paire d'instructions: 
NOT +AND : 


Listing 1.318 : ARM (Mode ARM) 


BIC RO, RO, #0x40 


Mettre à 0 un bit spécifique (spécifié lors de l'exécution) 


Listing 1.319 : C/C++ 


value=value&(-(1<<n)) ; 


Listing 1.320 : x86 


; CL=n 

MOV REG, 1 

SHL REG, CL 

NOT REG 

AND input value, REG 


1.28.7 Exercices 
* http://challenges.re/67 
* http://challenges.re/68 
* http://challenges.re/69 
* http://challenges.re/70 
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1.29 Générateur congruentiel linéaire comme gé- 


nérateur de nombres pseudo-aléatoires 


Peut-étre que le générateur congruentiel linéaire est le moyen le plus simple possible 
de générer des nombres aléatoires. 


Ce n'est plus très utilisé aujourd'hui!??, mais il est si simple (juste une multiplication, 
une addition et une opération AND) que nous pouvons l'utiliser comme un exemple. 


#include <stdint.h> 

// constantes du livre Numerical Recipes 
define RNG a 1664525 

define RNG c 1013904223 


static uint32 t rand state; 


void my srand (uint32 t init) 


1 
rand state-init; 
} 
int my_rand () 
{ 
rand_state=rand_state*RNG_a; 
rand_state=rand_state+RNG_c; 
return rand state € Ox7fff; 
} 


Il y a deux fonctions: la premiére est utilisée pour initialiser l'état interne, et la se- 
conde est appelée pour générer un nombre pseudo-aléatoire. 


Nous voyons que deux constantes sont utilisées dans l'algorithme. Elles proviennent 
de [William H. Press and Saul A. Teukolsky and William T. Vetterling and Brian P. Flan- 
nery, Numerical Recipes, (2007)]. 


Définissons-les en utilisant la déclaration C/C++ define. C'est une macro. 


La différence entre une macro C/C++ et une constante est que toutes les macros 
sont remplacées par leur valeur par le pré-processeur C/C++, et qu'elles n'utilisent 
pas de mémoire, contrairement aux variables. 


Par contre, une constante est une variable en lecture seule. 


Il est possible de prendre un pointeur (ou une adresse) d'une variable constante, 
mais c'est impossible de faire ca avec une macro. 


La dernière opération AND est nécessaire car d'après le standard C my rand() doit 
renvoyer une valeur dans l'intervalle 0..32767. 


Si vous voulez obtenir des valeurs pseudo-aléatoires 32-bit, il suffit d'omettre la 
derniére opération AND. 


1521 e twister de Mersenne est meilleur. 
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1.29.1 x86 


Listing 1.321 : MSVC 2013 avec optimisation 


_BSS SEGMENT 
rand_state DD 01H DUP (?) 


_BSS ENDS 

_init$ = 8 

_srand PROC 
mov eax, DWORD PTR _init$[esp-4] 
mov DWORD PTR rand state, eax 
ret 0 

_srand ENDP 

TEXT | SEGMENT 

rand PROC 
imul eax, DWORD PTR rand state, 1664525 
add eax, 1013904223 ; 3c6ef35fH 
mov DWORD PTR rand state, eax 
and eax, 32767 ; 00007fffH 
ret 0 

rand  ENDP 

TEXT ENDS 


Nous les voyons ici: les deux constantes sont intégrées dans le code. Il n'y a pas de 
mémoire allouée pour elles. 


La fonction my srand() copie juste sa valeur en entrée dans la variable rand state 
interne. 


my rand() la prend, calcule le rand state suivant, le coupe et le laisse dans le 
registre EAX. 


La version non optimisée est plus verbeuse: 


Listing 1.322 : MSVC 2013 sans optimisation 


_BSS SEGMENT 
rand state DD 01H DUP (?) 


_BSS ENDS 

_init$ = 8 

_srand PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR  init$[ebp] 
mov DWORD PTR _rand_state, eax 
pop ebp 
ret 0 

 srand ENDP 


TEXT | SEGMENT 
rand PROC 
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push ebp 
mov ebp, esp 
imul eax, DWORD PTR rand state, 1664525 
mov DWORD PTR _rand_state, eax 
mov ecx, DWORD PTR _rand_state 
add ecx, 1013904223 ; 3c6ef35fH 
mov DWORD PTR _rand_state, ecx 
mov eax, DWORD PTR rand state 
and eax, 32767 ; 00007fffH 
pop ebp 
ret 0 

rand  ENDP 

TEXT ENDS 

1.29.2 x64 


La version x64 est essentiellement la méme et utilise des registres 32-bit au lieu de 
64-bit (car nous travaillons avec des valeurs de type int ici). 


Mais my srand() prend son argument en entrée dans le registre ECX plutót que sur 
la pile: 


Listing 1.323 : MSVC 2013 x64 avec optimisation 


_BSS SEGMENT 
rand state DD 01H DUP (?) 
_BSS ENDS 


init$ = 8 

my srand PROC 

; ECX = argument en entrée 
mov DWORD PTR rand state, ecx 
ret 0 

my srand ENDP 


_ TEXT SEGMENT 
my rand PROC 
imul eax, DWORD PTR rand state, 1664525 ; 0019660dH 


add eax, 1013904223 ; 3c6ef35fH 
mov DWORD PTR rand state, eax 
and eax, 32767 ; 00007fffH 
ret 0 


my rand ENDP 


TEXT ENDS 


Le compilateur GCC génére en grande partie le méme code. 


1.29.3 ARM 32-bit 
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Listing 1.324 : avec optimisation Keil 6/2013 (Mode ARM) 


my srand PROC 


my rand PROC 
LDR 
LDR 
LDR 
MUL 
LDR 
ADD 
STR 


r1,|L0.52] 
r0, [r1,#0] 
lr 


ro, |L0.52] 
r2,|L0.56] 
r1,[ro,*0] 
r1,r2,r1 

r2,|L0.60] 
rl,rl,r2 

r1,[ro,*0] 


; AND avec Ox7FFF: 


|LO.52| 
|LO.56| 


|LO.60 | 
DCD 


r0,r1,#17 
r0,r0,#17 
lr 


|| .data] | 


0x0019660d 


0x3c6ef35f 


, 


charger un pointeur sur rand state 
sauver rand state 


charger un pointeur sur rand state 
charger RNG a 

charger rand state 

charger RNG c 


sauver rand state 


AREA ||.data||, DATA, ALIGN-2 


rand state 
DCD 


0x00000000 


Il n'est pas possible d'intégrer une constante 32-bit dans des instructions ARM, donc 
Keil doit les stocker à l'extérieur et en outre les charger. Une chose intéressante est 
qu'il n'est pas possible non plus d'intégrer la constante Ox7FFF. Donc ce que fait Keil 
est de décaler rand state vers la gauche de 17 bits et ensuite la décale de 17 bits 
vers la droite. Ceci est analogue à la déclaration (rand state << 17) > 17 en C/C++. Il 
semble que ca soit une opération inutile, mais ce qu'elle fait est de mettre à zéro 
les 17 bits hauts, laissant les 15 bits bas inchangés, et c'est notre but aprés tout. 


Keil avec optimisation pour le mode Thumb génére essentiellement le méme code. 


1.29.4 MIPS 


Listing 1.325 : avec optimisation GCC 4.4.5 (IDA) 


(rand state >> 16) 


my srand: 

; stocker $a0 dans rand state: 
lui $v0, 
jr $ra 
SW $a, 


rand state 
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my_rand: 
; charger rand state dans $v0: 

lui $v1, (rand state >> 16) 

lw $v0, rand state 

or $at, $zero ; slot de délai de branchement 
; multiplier rand state dans $v0 par 1664525 (RNG a): 

sll $al, $v0, 2 

su $20, $v0, 4 

addu $a0, $al, $a0 

sll $al, $a0, 6 


subu $a0, $al, $a0 
addu $a0, $v0 


sll $al, $a0, 5 
addu $a0, $al 

sll $a0, 3 

addu $vO, $a0, $v0 
sll $a0, $v0, 2 


addu $v0, $a0 
; ajouter 1013904223 (RNG c) 
; l'instruction LI est la fusion par IDA de LUI et ORI 
li $a0, Ox3C6EF35F 
addu $v0, $a0 
; stocker dans rand state: 
SW $v0, (rand state € OxFFFF) ($v1) 
jr $ra 
andi $v0, Ox7FFF ; slot de délai de branchement 


Quah, ici nous ne voyons qu'une seule constante (Ox3C6EF35F ou 1013904223). Ou 
est l'autre (1664525)? 


Il semble que la multiplication soit effectuée en utilisant seulement des décalages 
et des additions! Vérifions cette hypothése: 


define RNG a 1664525 


int f (int a) 


1 
return a*RNG a; 

} 

Listing 1.326 : GCC 4.4.5 avec optimisation (IDA) 
fs 

sll $v1, $a0, 2 

sll $v0, $a0, 4 

addu $v0, $vl, $v0 

sll $vl, $v0, 6 


subu $v0, $vl, $v0 
addu $v0, $a0 


su $v1, $v0, 5 
addu $v0, $v1 
su $v0, 3 


addu $a0, $vO, $a0 
sll $v0, $a0, 2 
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jr $ra 
addu $v0, $a0, $v0 ; branch delay slot 


En effet! 


Relocations MIPS 


Nous allons nous concentrer sur comment les opérations comme charger et stocker 
dans la mémoire fonctionnent. 


Les listings ici sont produits par IDA, qui cache certains détails. 


Nous allons lancer objdump deux fois: pour obtenir le listing désassemblé et aussi 
la liste des relogements: 


Listing 1.327 : GCC 4.4.5 avec optimisation (objdump) 


# objdump -D rand 03.0 


00000000 <my_srand>: 


0: 3c020000 lui v0,0x0 

4: 03e00008 jr ra 

8: ac440000 SW a0,0(v0) 

0000000c «my rand»: 

C: 3c030000 lui v1,0x0 
10: 8c620000 lw v0,0(v1) 
14: 00200825 move at,at 
18: 00022880 sll al,v0,0x2 
1c: 00022100 sll a0,v0,0x4 
20: 00242021 addu a0,a1,a0 
24: 00042980 sll al,a0,0x6 
28: 00242023 subu a0,a1,a0 
2c: 00822021 addu a0,a0,v0 
30: 00042940 sll al,a0,0x5 
34: 00852021 addu a0,a0,al 
38: 000420c0 sll a0,a0,0x3 
3c: 00821021 addu v0,a0,v0 
40: 00022080 sll a0,v0,0x2 
44: 00441021 addu v0,v0,ab 
48: 3c043c6e lui a0,0x3c6e 
4C: 3484f35f ori a0,a0,0xf35f 
50: 00441021 addu v0,v0,a0 
54: ac620000 SW v0,0(v1) 
58: 03e00008 jr ra 
5c: 30427fff andi v0,v0,0x7fff 


# objdump -r rand 03.0 
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RELOCATION RECORDS FOR [.text]: 


OFFSET TYPE VALUE 
00000000 R MIPS HI16 „bss 
00000008 R MIPS L016 „bss 
0000000c R MIPS HI16 „bss 
00000010 R MIPS L016 „bss 
00000054 R MIPS L016 .bss 


Considérons les deux relogements pour la fonction my srand(). 


La première, pour l'adresse O a un type de R MIPS HI16 et la seconde pour l'adresse 
8 a un type de R MIPS L016. 


Cela implique que l'adresse du début du segment .bss soit écrite dans les instruc- 
tions a l'adresse O (partie haute de l'adresse) et 8 (partie basse de l'adresse). 


La variable rand_state est au tout début du segment .bss. 


Donc nous voyons des zéros dans les opérandes des instructions LUI et SW, caril n'y 
a encore rien ici— le compilateur ne sait pas quoi y écrire. 


L'éditeur de liens va arranger cela, et la partie haute de l'adresse sera écrite dans 
l'opérande de LUI et la partie basse de l'adresse—dans l'opérande de SW. 


SW va ajouter la partie basse de l'adresse avec le contenu du registre $VO (la partie 
haute y est). 


C'est la méme histoire avec la fonction my rand() : la relogement R MIPS HI16 in- 
dique à l'éditeur de liens d'écrire la partie haute. 


Donc la partie haute de l'adresse de la variable rand state se trouve dans le registre 
$V1. 


L'instruction LW à l'adresse 0x10 ajoute les parties haute et basse et charge la valeur 
de la variable rand state dans $VO. 


L'instruction SW à l'adresse 0x54 fait à nouveau la somme et stocke la nouvelle valeur 
dans la variable globale rand state. 


IDA traite les relogements pendant le chargement, cachant ainsi ces détails, mais 
nous devons les garder à l'esprit. 


1.29.5 Version thread-safe de l'exemple 


La version thread-safe de l'exemple sera montrée plus tard: 6.2.1 on page 966. 


1.30 Structures 


Moyennant quelques ajustements, on peut considérer qu'une structure C/C++ n'est 
rien d'autre qu'un ensemble de variables, pas toutes nécessairement du méme type, 
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et toujours stockées en mémoire côte à côte !^?. 


1.30.1 MSVC: exemple SYSTEMTIME 


Considérons la structure win32 SYSTEMTIME?** qui décrit un instant dans le temps. 
Voici comment elle est définie: 


Listing 1.328 : WinBase.h 


typedef struct  SYSTEMTIME { 
WORD wYear; 
WORD wMonth; 
WORD wDayOfWeek; 
WORD wDay; 
WORD wHour; 
WORD wMinute; 
WORD wSecond; 
WORD wMilliseconds; 
) SYSTEMTIME, *PSYSTEMTIME; 


Écrivons une fonction C pour récupérer l'instant qu'il est: 


#include «windows.h» 
#include <stdio.h> 


void main() 


{ 
SYSTEMTIME t; 
GetSystemTime (&t); 
printf ("%04d-%02d-%02d %02d:%02d:%02d\n", 
t.wYear, t.wMonth, t.wDay, 
t.wHour, t.wMinute, t.wSecond) ; 
return; 
}; 


Le résultat de la compilation avec MSVC 2010 donne: 


Listing 1.329 : MSVC 2010 /GS- 


t$ = -16 ; size = 16 
_main PROC 
push ebp 
mov ebp, esp 
sub esp, 16 
lea eax, DWORD PTR _t$[ebp] 
push eax 
call DWORD PTR imp GetSystemTime@4 
movzx ecx, WORD PTR _t$[ebp+12] ; wSecond 
push ecx 


153AKA «conteneur hétérogène » 
154MSDN: SYSTEMTIME structure 
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movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
push 
call 
add 
xor 
mov 
pop 
ret 

main 


edx, WORD PTR t$[ebp+10] ; wMinute 
edx 

eax, WORD PTR t$[ebp«8] ; wHour 
eax 

ecx, WORD PTR t$[ebp«6] ; wDay 

ecx 

edx, WORD PTR t$[ebp«2] ; wMonth 
edx 

eax, WORD PTR t$[ebp] ; wYear 

eax 

OFFSET $SG78811 ; '%04d-%02d-%02d %02d:%02d:%02d', OaH, OOH 
| printf 

esp, 28 

eax, eax 

esp, ebp 

ebp 

0 

ENDP 


16 octets sont réservés sur la pile pour cette structure, ce qui correspond exactement 
à sizeof (WORD)*8. La structure comprend effectivement 8 variables d'un WORD 


chacun. 


Faites attention au fait que le premier membre de la structure est le champ wYear. On 
peut donc considérer que la fonction GetSystemTime()*>°recoit comme argument 
un pointeur sur la structure SYSTEMTIME, ou bien qu'elle recoit un pointeur sur le 
champ wYear. Et en fait c'est exactement la méme chose! GetSystemTime() écrit 
l'année courante dans à l'adresse du WORD qu'il a recu, avance de 2 octets, écrit le 
mois courant et ainsi de suite. 


155MSDN: SYSTEMTIME structure 
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OllyDbg 


Compilons cet exemple avec MSVC 2010 et les options /GS- /MD, puis exécutons le 
avec OllyDbg. 


Ouvrons la fenétre des données et celle de la pile à l'adresse du premier argument 
fourni à la fonction GetSystemTime(), puis attendons que cette fonction se termine. 
Nous constatons : 


CPU - main thread, module systemtime = [Dl xl 


gisters (FPU) 

AX BBZEFBS4 

AL. 41 99600304 

| Sr a 

TR OS: L«&KERNELS2., Get System 

PTR SS:ELOCRL. 1] i | 

WORD PTR SS: CLOCAL. 2+2] : > poe systemt ime. GO 

WORD PTR SS: CLOCAL.2 : ^ 98991618 temt ime. 00991010 
ENT en ‘ C ø B(FFFFFFFF) 
S: LLOCRL. 342 : C @( FFFFFFFF) 
SS: [LOCA ‘ nao s @( FFFFFFFF) 
SS: LLOCRL. @( FFFFFFFF) 


VEFODGGG( FFF) 
at FFFFFFFF) 


LastErr 00000008 ERROR SUCCESS 
E,BE,NS,PE,GE,LE) bé 


UNICODE "than" 


GG2EFED4| 99 


Fig. 1.104: OllyDbg : Juste après l'appel à GetSystemTime() 


Sur mon ordinateur, le résultat de l'appel à la fonction est 9 décembre 2014, 22:29:52: 


Listing 1.330 : printf() output 


2014-12-09 22:29:52 


Nous observons donc ces 16 octets dans la fenétre de données: 


DE 07 OC 00 02 00 09 00 16 00 1D 00 34 00 D4 03 


Chaque paire d'octets représente l'un des champs de la structure. Puisque nous 
sommes en mode petit-boutien l'octet de poids faible est situé en premier, suivi de 
l'octet de poids fort. 


Les valeurs effectivement présentes en mémoire sont donc les suivantes: 
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nombre hexadécimal | nombre décimal | nom du champ 
0x07DE 2014 wYear 

0x000C 12 wMonth 
0x0002 2 wDayOfWeek 
0x0009 9 wDay 

0x0016 22 wHour 

0x001D 29 wMinute 
0x0034 52 wSecond 
0x03D4 980 wMilliseconds 


Les mémes valeurs apparaissent dans la fenétre de la pile, mais elle y sont regrou- 
pées sous forme de valeurs 32 bits. 


La fonction printf() utilise les valeurs qui lui sont nécessaires et les affiche à la 
console. 


Bien que certaines valeurs telles que (wDayOfWeek et wMilliseconds) ne soient pas 
affichées par printf(), elles sont bien présentes en mémoire, prétes à étre utili- 
sées. 


Remplacer la structure par un tableau 


Le fait que les champs d'une structure ne sont que des variables situées cóte-à-cóte 
peut étre aisément démontré de la maniére suivante. Tout en conservant à l'esprit 
la description de la structure SYSTEMTIME, il est possible de réécrire cet exemple 
simple de la maniére suivante: 


#include «windows.h» 
#include <stdio.h> 


void main() 


{ 
WORD array[8]; 
GetSystemTime (array); 
printf ("%04d-%02d-%02d %02d:%02d:%02d\n", 
array[0] /* wYear */, array[1] /* wMonth */, array[3] /* wDay */, 
array[4] /* wHour */, array[5] /* wMinute */, array[6] /* wSecond 7 
S */); 
return; 
}; 


Le compilateur ronchonne certes un peu: 


systemtime2.c(7) : warning C4133: 'function' : incompatible types - from ' 2 


G WORD [8]' to 'LPSYSTEMTIME!' 


Mais, il consent quand méme a produire le code suivant: 


Listing 1.331 : sans optimisation MSVC 2010 


1$5678573 DB '%04d-%02d-%02d %02d:%02d:%02d', OaH, OOH 
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_array$ = -16 

main PROC 
push 
mov 
sub 
lea 
push 
call 
movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
push 
call 
add 
xor 
mov 
pop 
ret 


main  ENDP 


; Size - 16 


ebp 

ebp, esp 

esp, 16 

eax, DWORD PTR array$[ebp] 
eax 

DWORD PTR imp GetSystemTime@4 

ecx, WORD PTR _array$[ebp+12] ; wSecond 
ecx 

edx, WORD PTR _array$[ebp+10] ; wMinute 
edx 

eax, WORD PTR _array$[ebp+8] ; wHoure 
eax 

ecx, WORD PTR _array$[ebp+6] 
ecx 

edx, WORD PTR _array$[ebp+2] ; wMonth 
edx 

eax, WORD PTR array$[ebp] ; wYear 
eax 

OFFSET $SG78573 ; 
| printf 

esp, 28 

eax, eax 

esp, ebp 

ebp 

0 


; wDay 


'%04d-%02d-%02d %02d:%02d:%02d', OaH, OOH 


Qui fonctionne a l'identique du précédent! 


Il est extrêmement intéressant de constater que le code assembleur produit est 
impossible a distinguer de celui produit par la compilation précédente. 


Et ainsi celui qui obServe ce code assembleur est incapable de décider avec certitude 
si une structure ou un tableau était déclaré dans le code source en C. 


Cela étant, aucun esprit sain ne s’amuserait a déclarer un tableau ici. Car il faut 
aussi compter avec la possibilité que la structure soit modifiée par les développeurs, 
que les champs soient triés dans un autre ordre ... 


Nous n'étudierons pas cet exemple avec OllyDbg, car les résultats seraient iden- 
tiques à ceux que nous avons observé en utilisant la structure. 


1.30.2 Allouons de l'espace pour une structure avec malloc() 


Il est parfois plus simple de placer une structure sur le tas que sur la pile: 


#include «windows.h» 
#include <stdio.h> 


void main() 


{ 
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SYSTEMTIME *t; 


t=(SYSTEMTIME *)malloc (sizeof (SYSTEMTIME)); 


GetSystemTime (t); 


printf ("%04d-%02d-%02d %02d:%02d:%02d\n", 
t->wYear, t->wMonth, t->wDay, 
t->wHour, t->wMinute, t->wSecond) ; 


free (t); 


return; 


}; 


Compilons cet exemple en utilisant l'option (/0x) qui facilitera nos observations. 


Listing 1.332 : MSVC avec optimisation 


main 
push 
push 
call 
add 
mov 
push 
call 
movzx 
movzx 
movzx 
push 
movzx 
push 
movzx 
push 
movzx 
push 
push 
push 
push 
call 
push 
call 
add 
xor 
pop 
ret 
main 


_mal loc 

esp, 4 

esi, eax 

esi 

DWORD PTR imp GetSystemTime@4 
eax, WORD PTR [esi+12] ; wSecond 
ecx, WORD PTR [esi+10] ; wMinute 
edx, WORD PTR [esi+8] ; wHour 
eax 

eax, WORD PTR [esi+6] ; wDay 

ecx 

ecx, WORD PTR [esi+2] ; wMonth 
edx 

edx, WORD PTR [esi] ; wYear 

eax 

ecx 

edx 

OFFSET $SG78833 

| printf 

esi 

_free 

esp, 32 

eax, eax 

esi 

0 

ENDP 


Puisque sizeof(SYSTEMTIME) - 16 c'est aussi le nombre d'octets qui doit étre al- 
loué par malloc(). Celui-ci renvoie dans le registre EAX un pointeur vers un bloc 
mémoire fraichement alloué. Puis le pointeur est copié dans le registre ESI. La fonc- 
tion win32 GetSystemTime() prend soin que la valeur de ESI soit la méme à l'issue 
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de la fonction que lors de son appel. C'est pourquoi nous pouvons continuer à l'uti- 
liser aprés sans avoir eu besoin de le sauvegarder. 


Tiens, une nouvelle instruction —MOVZX (Move with Zero eXtend). La plupart du 
temps, elle peut étre utilisée comme MOVSX. La différence est qu'elle positionne sys- 
tématiquement les bits supplémentaires à O. Elle est utilisée ici car printf() attend 
une valeur sur 32 bits et que nous ne disposons que d'un WORD dans la structure — 
c'est à dire une valeur non signée sur 16 bits. Il nous faut donc forcer à zéro les bits 
16 à 31 lorsque le WORD est copié dans un int, sinon nous risquons de récupérer 
des bits résiduels de la précédente opération sur le registre. 


Dans cet exemple, il reste possible de représenter la structure sous forme d'un ta- 
bleau de 8 WORDs: 


#include «windows.h» 
#include <stdio.h> 


void main() 


{ 
WORD *t; 
t=(WORD *)malloc (16); 
GetSystemTime (t); 
printf ("%04d-%02d-%02d %02d:%02d:%02d\n", 
t[0] /* wYear */, t[1] /* wMonth */, t[3] /* wDay */, 
t[4] /* wHour */, t[5] /* wMinute */, t[6] /* wSecond */); 
free (t); 
return; 
}; 


Nous avons alors: 


Listing 1.333 : MSVC avec optimisation 


$SG78594 DB '9504d-*502d-*s02d %02d:%02d:%02d', OaH, OOH 
main PROC 

push esi 

push 16 

call _malloc 

add esp, 4 

mov esi, eax 

push esi 


call DWORD PTR _ imp  GetSystemTime@4 
movzx eax, WORD PTR [esi+12] 

movzx ecx, WORD PTR [esi+10] 

movzx edx, WORD PTR [esi+8] 

push eax 

movzx eax, WORD PTR [esi+6] 

push ecx 
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movzx ecx, WORD PTR [esi+2] 


push edx 
movzx edx, WORD PTR [esi] 
push eax 
push ecx 
push edx 
push OFFSET $5G78594 
call _printf 
push esi 
call _free 
add esp, 32 
xor eax, eax 
pop esi 
ret 0 
main  ENDP 


Encore une fois nous obtenons un code qu'il n'est pas possible de discerner du pré- 
cédent. 


Et encore une fois, vous n'avez pas intérét à faire cela, sauf si vous savez exactement 
ce que vous faites. 

1.30.3 UNIX: struct tm 

Linux 


Prenons pour exemple la structure tm dans l'en-téte time.h de Linux: 


#include <stdio.h> 
#include <time.h> 


void main() 


{ 
struct tm t; 
time t unix time; 
unix time-time (NULL); 
localtime r (&unix time, &t); 
printf ("Year: %d\n", t.tm_year+1900) ; 
printf ("Month: %d\n", t.tm mon); 
printf ("Day: %d\n", t.tm mday); 
printf ("Hour: %d\n", t.tm hour); 
printf ("Minutes: %d\n", t.tm min); 
printf ("Seconds: %d\n", t.tm sec); 
}; 


Compilons l'exemple avec GCC 4.4.1: 


Listing 1.334 : GCC 4.4.1 


main proc near 
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push 
mov 
and 
sub 
mov 
call 
mov 
lea 
lea 
mov 
mov 
call 
mov 
lea 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
call 
leave 
retn 
main endp 


ebp 

ebp, esp 

esp, OFFFFFFFOh 

esp, 40h 

dword ptr [esp], 0 ; premier argument de la fonction time() 
time 

[esp+3Ch], eax 


eax, [esp+3Ch] ; récupération de la valeur retournée par time() 
edx, [esp+10h] ; la structure tm est à l'adresse ESP+10h 
[esp+4], edx ; passons le pointeur vers la structure begin 
[esp], eax Po... et le pointeur retourné par time() 
localtime r 

eax, [esp+24h] ; tm year 

edx, [eax+76Ch] ; edx=eax+1900 

eax, offset format ; "Year: %d\n" 

[esp+4], edx 

[esp], eax 

printf 

edx, [esp+20h] ; tm mon 


eax, offset aMonthD ; "Month: %d\n" 
[esp+4], edx 

[esp], eax 

printf 

edx, [esp+1Ch] ; tm mday 

eax, offset aDayD ; "Day: %d\n" 
[esp+4], edx 

[esp], eax 

printf 

edx, [esp+18h] ; tm hour 

eax, offset aHourD ; "Hour: %d\n" 
[esp+4], edx 

[esp], eax 

printf 

edx, [esp+14h] ; tm min 

eax, offset aMinutesD ; "Minutes: %d\n" 
[esp+4], edx 

[esp], eax 

printf 

edx, [esp+10h] 

eax, offset aSecondsD ; "Seconds: %d\n" 
[esp+4], edx ; tm sec 
[esp], eax 

printf 


IDA n'a pas utilisé le nom des variables locales pour identifier les éléments de la pile. 
Mais comme nous sommes déjà des rétro ingénieurs expérimentés :-) nous pouvons 
nous en passer dans cet exemple simple. 


Notez l'instruction lea edx, [eax+76Ch] —qui incrémente la valeur de EAX de 0x76C 
(1900) sans modifier aucun des drapeaux. Référez-vous également à la section au 
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sujet de LEA (.1.6 on page 1333). 
GDB 


Tentons de charger l'exemple dans GDB ?°° : 


Listing 1.335 : GDB 


dennis@ubuntuvm:~/polygon$ date 

Mon Jun 2 18:10:37 EEST 2014 
dennis@ubuntuvm:~/polygon$ gcc GCC tm.c -o GCC tm 
dennis@ubuntuvm:~/polygon$ gdb GCC tm 

GNU gdb (GDB) 7.6.1-ubuntu 


Reading symbols from /home/dennis/polygon/GCC tm...(no debugging symbols 7 
y found)...done. 

(gdb) b printf 

Breakpoint 1 at 0x8048330 

(gdb) run 

Starting program: /home/dennis/polygon/GCC tm 


Breakpoint 1, _ printf (format=0x80485c0 "Year: %d\n") at printf.c:29 
29 printf.c: No such file or directory. 
(gdb) x/20x $esp 


OxbffffOdc: 0x080484c3 0x080485c0 0x000007de 0x00000000 
OxbffffOec: 0x08048301 0x538c93ed 0x00000025 0x0000000a 
OxbffffOfc: 0x00000012 0x00000002 0x00000005 0x00000072 
Oxbffff10c: 0x00000001 0x00000098 0x00000001 0x00002a30 
Oxbffffllc: 0x0804b090 0x08048530 0x00000000 0x00000000 
(gdb) 


Nous retrouvons facilement notre structure dans la pile. Commencons par observer 
sa définition dans time.h : 


Listing 1.336 : time.h 


struct tm 

1 
int tm sec; 
int tm min; 
int tm hour; 
int tm mday; 
int tm mon; 
int tm year; 
int tm wday; 
int tm yday; 
int tm isdst; 

}; 


Faites attention au fait qu'ici les champs sont des int sur 32 bits et non des WORD 
comme dans SYSTEMTIME. 


156| e résultat date est légèrement modifié pour les besoins de la démonstration, car il est bien entendu 
impossible d'exécuter GDB aussi rapidement. 
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Voici donc les champs de notre structure tels qu'ils sont présents dans la pile: 


OxbffffOdc: 0x080484c3 0x080485c0 0x000007de 0x00000000 

Oxbffff0ec: 0x08048301 0x538c93ed 0x00000025 sec 0x0000000a min 

OxbffffOfc: 0x00000012 hour 0x00000002 mday 0x00000005 mon . 0x00000072 7 
S year 

OxbfffflOc: 0x00000001 wday 0x00000098 yday 0x00000001 isdst 0x00002a30 

Oxbffffllc: 0x0804b090 0x08048530 0x00000000 0x00000000 


Représentés sous forme tabulaire, cela donne: 


Hexadécimal | Décimal | nom 
0x00000025 | 37 tm sec 
0x0000000a | 10 tm min 
0x00000012 | 18 tm hour 
0x00000002 | 2 tm_mday 
0x00000005 | 5 tm_mon 
0x00000072 | 114 tm_year 
0x00000001 | 1 tm_wday 
0x00000098 | 152 tm_yday 
0x00000001 | 1 tm_isdst 


C'est trés similaire à SYSTEMTIME (1.30.1 on page 443), Là encore certains champs 
sont présents qui ne sont pas utilisés tels que tm wday, tm yday, tm isdst. 


ARM 
avec optimisation Keil 6/2013 (Mode Thumb) 


Méme exemple: 


Listing 1.337 : avec optimisation Keil 6/2013 (Mode Thumb) 


var 38 - -0x38 

var 34 - -0x34 

var 30 - -0x30 

var 2C = -0x2C 

var 28 - -0x28 

var 24 = -0x24 

timer = -0xC 
PUSH (LR) 
MOVS RO, 40 ; timer 
SUB SP, SP, 40x34 
BL time 
STR RO, [SP,#0x38+timer] 
MOV R1, SP ; tp 
ADD RO, SP, #0x38+timer ; timer 
BL localtime r 
LDR R1, -0x76C 
LDR RO, [SP,#0x38+var_24] 


ADDS R1, RO, R1 
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ADR RO, aYearD ; "Year: %d\n" 

BL . 2printf 

LDR R1, [SP,#0x38+var 28] 

ADR RO, aMonthD ; "Month: %d\n" 
BL . 2printf 

LDR R1, [SP,#0x38+var 2C] 

ADR RO, aDayD ; "Day: %d\n" 

BL . 2printf 

LDR R1, [SP,#0x38+var 30] 

ADR RO, aHourD ; "Hour: %d\n" 

BL . 2printf 

LDR R1, [SP,#0x38+var 34] 

ADR RO, aMinutesD ; "Minutes: %d\n" 
BL . 2printf 

LDR R1, [SP,#0x38+var_ 38] 

ADR RO, aSecondsD ; "Seconds: %d\n" 
BL . 2printf 

ADD SP, SP, 40x34 

POP {PC} 


avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


IDA reconnait la structure tm (car le logiciel a connaissance des arguments attendus 
par les fonctions de la librairie telles que Localtime r()), 


Il peut donc afficher les éléments de la structure ainsi que leurs noms. 


Listing 1.338 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


PUSH {R7,LR} 

MOV R7, SP 

SUB SP, SP, #0x30 

MOVS RO, #0 ; time t * 

BLX time 

ADD R1, SP, #0x38+var_34 ; struct tm * 
STR RO, [SP,#0x38+var_ 38] 

MOV RO, SP ; time t * 

BLX  localtime r 

LDR R1, [SP,#0x38+var 34.tm year] 
MOV RO, 0xF44 ; "Year: %d\n" 

ADD RO, PC ; char * 

ADDW R1, R1, #0x76C 

BLX  printf 

LDR R1, [SP,#0x38+var_34.tm_mon] 
MOV RO, OxF3A ; "Month: %d\n" 

ADD RO, PC ; char * 

BLX printf 

LDR R1, [SP,#0x38+var_34.tm_mday] 
MOV RO, OxF35 ; "Day: %d\n" 


WO YO Uu R WN E 
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0000000 
0000000 
0000000 
0000000 
0000000 
0000001 
0000001 
0000001 
0000001 
0000002 
0000002 
0000002 
0000002 


ADD 
BLX 
LDR 
MOV 
ADD 
BLX 
LDR 
MOV 
ADD 
BLX 
LDR 
MOV 
ADD 
BLX 
ADD 
POP 


0 tm 


0 tm sec DCD 
4 tm min DCD 
8 tm hour DCD 
C tm mday DCD 
0 tm mon DCD 
4 tm year DCD 
8 tm wday DCD 
C tm yday DCD 
0 tm isdst DCD 
4 tm gmtoff DCD 


RO, PC ; char * 

_ printf 

R1, [SP,#0x38+var 34.tm hour] 
RO, OxF2E ; "Hour: %d\n" 

RO, PC ; char * 

_ printf 

R1, [SP,#0x38+var 34.tm min] 
RO, OxF28 ; "Minutes: %d\n" 
RO, PC ; char * 

| printf 

R1, [SP,#0x38+var 34] 

RO, OxF25 ; "Seconds: %d\n" 
RO, PC ; char * 

| printf 

SP, SP, #0x30 

{R7,PC} 


struc ; (sizeof=0x2C, standard type) 


8 tm zone DCD ? ; offset 


C tm 


ends 


MIPS 


Listing 1.339 : avec optimisation GCC 4.4.5 (IDA) 


main: 


; Le nommage des champs dans les structures a été effectué manuellement car 
IDA ne les connaít pas: 


var 40 
var 38 
seconds 
minutes 
hour 
day 
month 
year 
var 4 


lui 


-0x40 
-0x38 
-0x34 
-0x30 
-0x2C 
-0x28 
-0x24 
-0x20 
-4 


$gp, ( gnu local gp >> 16) 
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addiu $sp, -0x50 


la $gp, ( gnu local gp € OxFFFF) 

SW $ra, Ox50+var 4($sp) 

sw $gp, Ox50+var 40($sp) 

lw $t9, (time € OxFFFF) ($gp) 

or $at, $zero ; Gaspillage par NOP du délai de branchement 

jalr $t9 

move $a0, $zero ; Gaspillage par NOP du délai de branchement 

lw $gp, Ox50+var 40($sp) 

addiu $a0, $sp, Ox50+var 38 

lw $t9, (localtime r € OxFFFF) ($9p) 

addiu $al, $sp, 0x50+seconds 

jalr $t9 

SW $v0, Ox50+var_38($sp) ; Utilisation du délai de branchement 

lw $gp, 0x50+var 40($sp) 

lw $al, Ox50+year($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

la $a0, $LCO # "Year: %d\n" 

jalr $t9 

addiu $al, 1900 ; branch delay slot 

lw $gp, Ox50+var 40($sp) 

lw $al, 0x50-«month($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

lui $a0, ($LC1 >> 16) # "Month: %d\n" 

jalr $t9 

la $20, ($LC1 € OxFFFF) # "Month: %d\n" ; Utilisation du délai de 
branchement 

lw $gp, Ox50+var 40($sp) 

lw $al, 0x504day($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

lui $a0, ($LC2 >> 16) # "Day: %d\n" 

jalr $t9 

la $20, ($LC2 € OxFFFF) # "Day: %d\n" ; Utilisation du délai de 
branchement 

lw $gp, Ox50+var 40($sp) 

lw $al, 0x50+hour($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

lui $20, ($LC3 >> 16) # "Hour: %d\n" 

jalr $t9 

la $20, ($LC3 € OxFFFF) # "Hour: %d\n" ; Utilisation du délai de 
branchement 

lw $gp, Ox50+var 40($sp) 

lw $al, 0x50+minutes ($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

lui $20, ($LC4 >> 16) # "Minutes: %d\n" 

jalr $t9 

la $20, ($LC4 € OxFFFF) # "Minutes: %d\n" ; Utilisation du délai de 
branchement 

lw $gp, Ox50+var 40($sp) 

lw $al, Ox50+seconds($sp) 

lw $t9, (printf € OxFFFF) ($gp) 

lui $20, ($LC5 >> 16) # "Seconds: %d\n" 

jalr $t9 

la $20, ($LC5 € OxFFFF) # "Seconds: %d\n" ; Utilisation du délai de 


branchement 
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lw $ra, Ox50+var 4($sp) 
or $at, $zero ; Gaspillage par NOP du délai de branchement 
jr $ra 
addiu $sp, 0x50 
$LCO: .ascii "Year: %d\n"<0> 
$LC1: .ascii "Month: %d\n"<0> 
$LC2: „ascii "Day: %d\n"<0> 
$LC3: .ascii "Hour: %d\n"<0> 
$LC4: .ascii "Minutes: %d\n"<0> 
$LC5: .ascii "Seconds: %d\n"<0> 


Dans cet exemple, le retard à l'exécution des instructions de branchement peuvent 
nous égarer. 


L'instruction addiu $al, 1900 en ligne 35 qui ajoute la valeur 1900 à l'année en 
est un exemple. N'oubliez pas qu'elle est exécutée avant que le l'instruction JALR 
ne fasse son effet. 


Structure comme un ensemble de valeurs 


Afin d'illustrer le fait qu'une structure n'est qu'une collection de variables située 
cóte-à-cóte, retravaillons notre exemple sur la base de la définition de la structure 
tm : listado.1.336. 


#include <stdio.h> 
#include <time.h> 


void main() 


{ 
int tm sec, tm min, tm hour, tm mday, tm mon, tm year, tm wday, tm yday” 
G , tm isdst; 
time t unix time; 
unix time-time (NULL); 
localtime r (&unix time, &tm sec); 
printf ("Year: %d\n", tm year-1900); 
printf ("Month: %d\n", tm mon); 
printf ("Day: %d\n", tm mday); 
printf ("Hour: %d\n", tm hour); 
printf ("Minutes: %d\n", tm min); 
printf ("Seconds: %d\n", tm sec); 

}; 


N.B. Le pointeur vers le champ tm sec est passé comme argument de la fonction 
localtime r, en tant que premier élément de la «structure ». 


Le compilateur nous alerte: 


Listing 1.340 : GCC 4.7.3 


458 


GCC_tm2.c: In function 'main': 

GCC tm2.c:11:5: warning: passing argument 2 of 'localtime r' from 7 
\ incompatible pointer type [enabled by default] 

In file included from GCC tm2.c:2:0: 


/usr/include/time 


8:59:12: note: expected ‘struct tm *' but argument is of 7 
y type ‘int *' 


Mais il génére cependant un fragment exécutable correspondant au code assem- 


bleur suivant: 


Listing 1.341 : GCC 4.7.3 


main proc near 
var_30 = dword ptr -30h 
var 2C - dword ptr -2Ch 
unix time = dword ptr -1Ch 
tm sec = dword ptr -18h 
tm min - dword ptr -14h 
tm hour  - dword ptr -10h 
tm mday = dword ptr -0Ch 
tm mon - dword ptr -8 
tm year = dword ptr -4 
push ebp 
mov ebp, esp 
and esp, OFFFFFFFOh 
sub esp, 30h 
call |. main 
mov [esp+30h+var_30], 0 ; arg 0 
call time 
mov [esp+30h+unix time], eax 


lea 
mov 
lea 
mov 
call 
mov 
add 
mov 
mov 
call 
mov 
mov 
mov 
call 
mov 
mov 
mov 
call 
mov 
mov 
mov 
call 


eax, [esp+30h+tm sec] 

[esp+30h+var_2C], eax 

eax, [esp+30h+unix_time] 

[esp+30h+var_30], eax 

localtime_r 

eax, [esp+30h+tm year] 

eax, 1900 

[esp+30h+var 2C], eax 

[esp+30h+var 30], offset aYearD ; "Year: %d\n" 
printf 

eax, [esp+30h+tm_mon] 

[esp+30h+var_2C], eax 

[esp+30h+var_30], offset aMonthD ; "Month: %d\n" 
printf 

eax, [esp+30h+tm_mday] 

[esp+30h+var_2C], eax 

[esp+30h+var_30], offset aDayD ; “Day: %d\n" 
printf 

eax, [esp+30h+tm hour] 

[esp+30h+var_2C], eax 

[esp+30h+var_30], offset aHourD ; “Hour: %d\n" 
printf 
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mov eax, [esp+30h+tm_min] 
mov [esp+30h+var_2C], eax 
mov [esp+30h+var_30], offset aMinutesD ; "Minutes: %d\n" 
call printf 
mov eax, [esp+30h+tm sec] 
mov [esp+30h+var_2C], eax 
mov [esp+30h+var_ 30], offset aSecondsD ; "Seconds: %d\n" 
call printf 
leave 
retn 
main endp 


Ce code est similaire a ce que nous avons déja vue et il n’est pas possible de dire si 
le code source original contenait une structure ou un groupe de variables. 


Et cela fonctionne. Mais encore une fois ce n’est pas une bonne pratique. 


En régle générale les compilateurs en l'absence d'optimisation allouent les variables 
sur la pile dans le méme ordre que celui dans lequel elles ont été déclarées dans le 
code source. Pour autant, ce n'est pas une garantie. 


Par ailleurs certains compilateurs peuvent vous avertir que les variables tm year, 
tm mon, tm mday, tm hour, tm min n'ont pas été initialisées avant leur utilisation, 
mais resteront muets au sujet de tm sec 


Le compilateur lui non plus ne sait pas qu'ils sont appelés à étre initialisés par la 
fonction Localtime r(). 


Nous avons chois cet exemple car tous les champs de la structure sont de type int. 


Tout ceci ne fonctionnerait pas sir les champs de la structure étaient des WORD de 
16 bits, tel que dans le cas de la structure SYSTEMTIME structure—GetSystemTime () 
les initialiserait de maniére erronée (puisque les variables locales sont alignées sur 
des frontiéres de 32bits). Vous en saurez plus à ce sujet dans la prochaine section: 
«Organisation des champs dans la structure » (1.30.4 on page 463). 


Une structure n'est donc qu'un groupe de variables disposées côte-à-côte en mé- 
moire. Nous pouvons dire que la structure est une instruction adressée au compi- 
lateur et l'obligeant à conserver le groupement des variables. Cela étant dans les 
toutes premiéres versions du langage C (avant 1972), la notion de structure n'exis- 
tait pas encore [Dennis M. Ritchie, The development of the C language, (1993)]?*”. 


Pas d'exemple de débogage ici. Le comportement est toujours le méme. 


Une structure sous forme de table de 32 bits 


#include <stdio.h> 
#include <time.h> 


void main() 


{ 


struct tm t; 


157 Aussi disponible en pdf 
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}; 


time t unix time; 
int i; 


unix time=time(NULL); 
localtime_r (&unix time, &t); 


for (i=0; i«9; i++) 
{ 
il; 


int tmp=((int*)&t) [ 
(%d)\n", tmp, tmp); 


printf ("Ox%08X 
$; 


Nous n'avons qu'à utiliser l'opérateur cast pour transformer notre pointeur vers une 
structure en un tableau de int's. Et cela fonctionne! Nous avons exécuté l'exemple 
à 23h51m45s le 26 juillet 2014. 


0x0000002D ( 
0x00000033 ( 
0x00000017 ( 
0x0000001A ( 
0x00000006 ( 
0x00000072 ( 
0x00000006 ( 
0x000000CE ( 
0x00000001 ( 


Les variables sont dans le méme ordre que celui dans lequel elles apparaissent dans 
la définition de la structure: 1.336 on page 452. 


Nous avons effectué la compilation avec: 


Listing 1.342 : avec optimisation GCC 4.8.1 


main proc near 


push ebp 

mov ebp, esp 

push esi 

push ebx 

and esp, OFFFFFFFOh 

sub esp, 40h 

mov dword ptr [esp], 0 ; timer 
lea ebx, [esp+14h] 

call time 

lea esi, [esp+38h] 

mov [esp+4], ebx ; tp 

mov [esp+10h], eax 

lea eax, [esp+10h] 

mov [esp], eax ; timer 
call _localtime_r 

nop 

lea esi, [esi+0] ; NOP 


loc 80483D8: 
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; EBX pointe sur la structure, 
; ESI pointe sur la fin de celle-ci. 


mov eax, [ebx] ; get 32-bit word from array 
add ebx, 4 ; prochain champ de la structure 
mov dword ptr [esp+4], offset a0x08xD ; "0x%08X (%d)\n" 
mov dword ptr [esp], 1 
mov [esp+0Ch], eax ; passage des arguments a printf() 
mov [esp+8], eax 
call |. printf chk 
cmp ebx, esi ; Avons-nous atteint la fin de la structure ? 
jnz short loc 80483D8 ; non - alors passons à la prochaine valeur 
lea esp, [ebp-8] 
pop ebx 
pop esi 
pop ebp 
retn 
main endp 


En fait, l'espace dans la pile est tout d'abord traité comme une structure, puis ensuite 
comme un tableau. 


Le pointeur sur le tableau permet méme de modifier les champs de la structure. 


Et encore une fois cette maniére de procéder est extrémement douteuse et pas du 
tout recommandée pour l'écriture d'un code qui atterrira en production. 


Exercice 


Tentez de modifier (en l'augmentant de 1) le numéro du mois, en traitant la structure 
comme s'il s'agissait d'un tableau. 
Une structure sous forme d'un tableau d'octets 


Nous pouvons aller plus loin. Utilisons l'opérateur cast pour transformer le pointeur 
en un tableau d'octets, puis affichons son contenu: 


#include <stdio.h> 
#include <time.h> 


void main() 


{ 
struct tm t; 
time t unix time; 
int i, j; 


unix time-time (NULL); 
localtime r (&unix time, &t); 
for (i20; i«9; i++) 


1 
for (j=0; j<4; j++) 
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printf ("0x%02X ", ((unsigned char*)&t) [i*4+j]); 
printf ("Xn"); 
}; 
}; 


0x2D 0x00 0x00 0x00 
0x33 0x00 0x00 0x00 
0x17 0x00 0x00 0x00 
Ox1A 0x00 0x00 0x00 
0x06 0x00 0x00 0x00 
0x72 0x00 0x00 0x00 
0x06 0x00 0x00 0x00 
OxCE 0x00 0x00 0x00 
0x01 0x00 0x00 0x00 


Cet exemple a été exécuté à 23h51m45s le 26 juillet 2014 158. Les valeurs sont 
identiques à celles du précédent affichage (1.30.3 on page 460), et bien entendu 
l'octet de poids faible figure en premier puisque nous sommes sur une architecture 
de type little-endian (2.2 on page 586). 


Listing 1.343 : avec optimisation GCC 4.8.1 


main proc near 


push ebp 

mov ebp, esp 

push edi 

push esi 

push ebx 

and esp, OFFFFFFFOh 

sub esp, 40h 

mov dword ptr [esp], 0 ; timer 
lea esi, [esp+14h] 

call time 

lea edi, [esp+38h] ; struct end 
mov [esp*4], esi ; tp 

mov [esp+10h], eax 

lea eax, [esp+10h] 

mov [esp], eax ; timer 
call _localtime_r 

lea esi, [esi+0] ; NOP 


; ESI pointe sur la structure située sur la pile. 
; EDI pointe sur la fin de la structure. 
loc 8048408: 

xor ebx, ebx ; j=0 


loc 804840A: 


movzx eax, byte ptr [esi+ebx] ; load byte 

add ebx, 1 ; J=]+1 

mov dword ptr [esp+4], offset a0x02x ; "0x%02X " 
mov dword ptr [esp], 1 


158| es dates et heures sont les mémes dans tous les exemples. Elles ont été éditées pour la clarté de la 
démonstration. 
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mov [esp+8], eax ; Fourniture a printf() des octets qui ont 
été chargés 
call |. printf chk 
cmp ebx, 4 
jnz short loc 804840A 
; Imprime un retour chariot (CR) 
mov dword ptr [esp], 0Ah ; c 
add esi, 4 
call | putchar 
cmp esi, edi ; Avons nous atteint la fin de la structure ? 
jnz short loc 8048408 ; j-0 
lea esp, [ebp-0Ch] 
pop ebx 
pop esi 
pop edi 
pop ebp 
retn 
main endp 


1.30.4 Organisation des champs dans la structure 


L'arrangemen 


t des champs au sein d'une structure est un élément trés important. 


Prenons un exemple simple: 


#include «std 

struct s 

1 
char a; 
int b; 
char c; 
int d; 

}; 


void f(struct 


{ 


printf (" 
Fi 
int main() 
{ 
struct s 
tmp.a=1; 
tmp.b=2; 
tmp.c=3; 
tmp.d=4; 
f (tmp); 
}; 


io.h> 


S S) 


a=%d; b=%d; c=%d; d=%d\n", s.a, s.b, s.c, s.d); 


tmp; 


Nous avons deux champs de type char (occupant chacun un octet) et deux autres — 
de type int (comportant 4 octets chacun). 


m 
© © ©  O U1 un H 
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x86 


Le résultat de la compilation est: 


Listing 1.344 : MSVC 2012 /GS- /ObO 


_tmp$ = -16 

_main PROC 
push ebp 
mov ebp, esp 
sub esp, 16 
mov BYTE PTR tmp$[ebp], 1 
mov DWORD PTR _tmp$[ebp+4], 2 
mov BYTE PTR _tmp$[ebp+81, 3 
mov DWORD PTR _tmp$[ebp+12], 4 
sub esp, 16 
temporaire 
mov eax, esp 
mov ecx, DWORD PTR tmp$[ebp] 
structure temporaire 
mov DWORD PTR [eax], ecx 
mov edx, DWORD PTR _tmp$[ebp+4] 
mov DWORD PTR [eax+4], edx 
mov ecx, DWORD PTR _tmp$[ebp+8] 
mov DWORD PTR [eax+8], ecx 
mov edx, DWORD PTR _tmp$[ebp+12] 
mov DWORD PTR [eax+12], edx 
call _f 
add esp, 16 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

_main ENDP 

_s$ = 8 ; size = 16 

?F@@YAXUS@@E@Z PROC ; f 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _s$[ebp+12] 
push eax 
movsx ecx, BYTE PTR _s$[ebp+8] 
push ecx 
mov edx, DWORD PTR _s$[ebp+4] 
push edx 
movsx eax, BYTE PTR _s$[ebp] 
push eax 
push OFFSET $SG3842 
call | printf 
add esp, 20 
pop ebp 
ret 0 


?f@@YAXUSE@@@Z ENDP ; f 


TEXT 


ENDS 


initialisation 
initialisation 
initialisation 
initialisation 


champ a 
champ b 
champ c 
champ d 


Allocation d'espace pour la structure 


Copie de notre structure dans la 


WO Y  U1 UNA 
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Nous passons la structure comme un tout, mais en réalité nous pouvons constater 
que la structure est copiée dans un espace temporaire. De l'espace est réservé pour 
cela ligne 10 et les 4 champs sont copiées par les lignes de 12 ... 19), puis le pointeur 
sur l'espace temporaire est passé a la fonction. 


La structure est recopiée au cas où la fonction f () viendrait à en modifier le contenu. 
Si cela arrive, la copie de la structure qui existe dans main() restera inchangée. 


Nous pourrions également utiliser des pointeurs C/C++. Le résulta demeurerait le 
méme, sans qu'il soit nécessaire de procéder à la copie. 


Nous observons que l'adresse de chaque champ est alignée sur un multiple de 4 
octets. C'est pourquoi chaque char occupe 4 octets (de méme qu'un int). Pourquoi 
en est-il ainsi? La réponse se situe au niveau de la CPU. Il est plus facile et performant 
pour elle d'accéder la mémoire et de gérer le cache de données en utilisant des 
adresses alignées. 


En revanche ce n'est pas trés économique en terme d'espace. 


Tentons maintenant une compilation avec l'option (/Zp1) (/Zpfn] indique qu'il faut 
compresser les structures en utilisant des frontiéres tous les n octets). 


Listing 1.345 : MSVC 2012 /GS- /Zp1 


main PROC 
push ebp 
mov ebp, esp 
sub esp, 12 
mov BYTE PTR tmp$[ebp], 1 ; Initialisation du champ a 
mov DWORD PTR tmp$[ebp-1], 2 ; Initialisation du champ b 
mov BYTE PTR tmp$[ebp+51, 3  ; Initialisation du champ c 
mov DWORD PTR tmp$[ebp+6], 4 ; Initialisation du champ d 
sub esp, 12 ; Allocation d'espace pour la structure 
temporaire 
mov eax, esp 
mov ecx, DWORD PTR tmp$[ebp] ; Copie de 10 octets 
mov DWORD PTR [eax], ecx 
mov edx, DWORD PTR _tmp$[ebp+4] 
mov DWORD PTR [eax+4], edx 
mov cx, WORD PTR _tmp$[ebp+8] 
mov WORD PTR [eax+8], cx 
call _f 
add esp, 12 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 
_main ENDP 
_ TEXT SEGMENT 
_s$ = 8 ; size = 10 
? f@@YAXUS@@@Z PROC Pe 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _s$[ebp+6] 
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push eax 

movsx ecx, BYTE PTR _s$[ebp+5] 
push ecx 

mov edx, DWORD PTR _s$[ebp+1] 
push edx 

movsx eax, BYTE PTR _s$[ebp] 
push eax 


push OFFSET $5G3842 
call printf 
add esp, 20 


pop ebp 
ret 0 
?f@@YAXUS@@@Z ENDP x df 


La structure n'occupe plus que 10 octets et chaque valeur de type char n'occupe 
plus qu'un octet. Quelles sont les conséquences ? Nous économisons de la place au 
prix d'un accés à ces champs moins rapide que ne pourrait le faire la CPU. 


La structure est également copiée dans main(). Cette opération ne s'effectue pas 
champ par champ mais par blocs en utilisant trois instructions MOV. Et pourquoi pas 
4? 


Tout simplement parce que le compilateur a décidé qu'il était préférable d'effectuer 
la copie en utilisant 3 paires d'instructions MOV plutót que de copier deux mots de 
32 bits puis 2 fois un octet ce qui aurait nécessité 4 paires d'instructions MOV. 


Ce type d'implémentation de la copie qui repose sur les instructions MOV plutót que 
sur l'appel à la fonction memcpy() est trés répandu. La raison en est que pour de 
petits blocs, cette approche est plus rapide qu'un appel à memcpy() : 3.14.1 on 
page 656. 


Comme vous pouvez le deviner, si la structure est utilisée dans de nombreux fichiers 
sources et objets, ils doivent tous étre compilés avec la méme convention de com- 
pactage de la structure. 


Au delà de l'option MSVC /Zp qui permet de définir l'alignement des champs des 
structures, il existe également l'option du compilateur Zpragma pack qui peut étre 
utilisée directement dans le code source. Elle est supportée aussi bien par MSVC?^??que 
pars GCC160, 


Revenons à la structure SYSTEMTIME qui contient des champs de 16 bits. Comment 
notre compilateur sait-il les aligner sur des frontiéres de 1 octet? 


Le fichier WinNT.h contient ces instructions: 


Listing 1.346 : WinNT.h 


#include "pshpackl.h" 


et celles-ci: 


159MSDN: Working with Packing Structures 
160Structure-Packing Pragmas 
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Listing 1.347 : WinNT.h 


#include "pshpack4.h" // L'alignement sur 4 octets est la 
valeur par défaut 


Le fichier PshPack1.h ressemble à ceci: 


Listing 1.348 : PshPack1.h 


#if ! (defined(lint) || defined(RC INVOKED)) 

sif ( MSC VER >= 800 && !defined( M I86)) || defined( PUSHPOP SUPPORTED) 
#pragma warning(disable:4103) 

sif !(defined( MIDL PASS )) || defined(  midl ) 
#pragma pack(push,1) 

#else 

#pragma pack(1) 

#endif 

#else 

#pragma pack(1) 

#endif 

#endif /* ! (defined(lint) || defined(RC INVOKED)) */ 


Ces instructions indiquent au compilateur comment compresser les structures défi- 
nies aprés #pragma pack. 
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OllyDbg et les champs alignés par défaut 


Examinons dans OllyDbg notre exemple lorsque les champs sont alignés par défaut 
sur des frontiéres de 4 octets: 


CPU - main thread, module packing 


ESP 
DWORD PTR SS: CARG. 4] 
18 Y TR CARG. 3] 
DWORD PTR SS: CARG. 2] 
BYTE PTR SS: [ARG.1] 
7180168 
&«HSUCR118.printf?»1 C & S O(FFFFFFFF) 
; C Bt FFFFFFFF) 
at FFFFFFFF) 
Bat FFFFFFFF) 


7EFDD@GG( FFF) 
BCFFFFFFFF) 


LastErr 989068606 ERROR SUCCESS 
O, NB, NE, A, NS, PE, GE, G) 


Fig. 1.105: OllyDbg : Before printf() execution 


Nous voyons nos quatre champs dans la fenétre de données. 


` ALZ 


Mais d'oü viennent ces octets aléatoires (0x30, 0x37, 0x01) situé à côté des premier 
(a) et troisième (c) champs? 


Si nous revenons à notre listing 1.344 on page 464, nous constatons que ces deux 
champs sont de type char. Seul un octet est écrit pour chacun d'eux: 1 et 3 respec- 
tivement (lignes 6 et 8). 


Les trois autres octets des deux mots de 32 bits ne sont pas modifiés en mémoire! 
Des débris aléatoires des précédentes opérations demeurent donc là. 


Ces débris n'influencent nullement le résultat de la fonction printf () parce que les 
valeurs qui lui sont passées sont préparés avec l'instruction MOVSX qui opère sur des 
octets et non pas sur des mots: listado.1.344 (lignes 34 et 38). 


L'instruction MOVSX (extension de signe) est utilisée ici car le type char est par défaut 
une valeur signée pour MSVC et GCC. Si l'un des types unsigned char ou uint8 t 
était utilisé ici, ce serait l'instruction MOVZX que le compilateur aurait choisi. 
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OllyDbg et les champs alignés sur des frontiéres de 1 octet 


Les choses sont beaucoup plus simples ici. Les 4 champs occupent 10 octets et les 
valeurs sont stockées cóte-a-cóte. 


ESP z 
DWORD PTR SS: CEBP+9E] aeree 


BYTE PTR SS: [ARG.2+1] Pta 
DWORD PTR SS: CEBP+9] 
BYTE PTR SS: [ARG. 1] 


T aapE2aoa ASC ^ BaDE1818 pack ing. @80E 181 
PTR DS: (<&MSUCR114. printf >I CO ES aa ^ at FFFFFFFF) 

C Bt FFFFFFFF) 
at FFFFFFFF) 
OLFFFFFFFF) 
TEFDDOaaatFFF) 
QCFFFFFFFF) 


06 LastErr 00000090 ERROR SUCCESS 
EFL 000900202 (NO, NB,NE,A,NS,PO, GE, G) 


RETURN from pac 


OFFSET packing. 


Fig. 1.106: OllyDbg : Avant appel de la fonction printf () 


ARM 
avec optimisation Keil 6/2013 (Mode Thumb) 


Listing 1.349 : avec optimisation Keil 6/2013 (Mode Thumb) 


. text: 0000003E exit ; CODE XREF: f+16 

. text: 0000003E 05 BO ADD SP, SP, #0x14 
. text: 00000040 00 BD POP {PC} 

. text: 00000280 f 

. text : 00000280 

. text: 00000280 var_18 = -0x18 


. text: 00000280 a 
. text: 00000280 b 

. text: 00000280 c = -0xC 
.text:00000280 d = 
.text:00000280 


Wu oM 
1 [| 
oo 
X ox 
hp 
e. 


.text:00000280 OF B5 PUSH {RO-R3, LR} 
.text:00000282 81 BO SUB SP, SP, #4 
.text:00000284 04 98 LDR RO, [SP,#16] ; d 
. text: 00000286 02 9A LDR R2, [SP,#8] ; b 
. text: 00000288 00 90 STR RO, [SP] 


.text:0000028A 68 46 MOV RO, SP 
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.text:0000028C 03 7B LDRB R3, [RO,+12] ae 

.text:0000028E 01 79 LDRB R1, [RO,+4] sa 

.text:00000290 59 AQ ADR RO, aADBDCDDD ; "a=%d; b=%d; 
c=%d; d=%d\n" 

. text: 00000292 05 FO AD FF BL __2printf 

.text:00000296 D2 E6 B exit 


Rappelons-nous que c'est une structure qui est passée ici et non pas un pointeur 
vers une structure. Comme les 4 premiers arguments d'une fonction sont passés 
dans les registres sur les processeurs ARM, les champs de la structure sont passés 
dans les registres RO -R3. 


LDRB charge un octet présent en mémoire et l'étend sur 32bits en prenant en compte 
son signe. Cette opération est similaire à celle effectuée par MOVSX dans les archi- 
tectures x86. Elle est utilisée ici pour charger les champs a et c de la structure. 


Un autre détail que nous remarquons aisément est que la fonction ne s'achéve pas 
sur un épilogue qui lui est propre. A la place, il y a un saut vers l'épilogue d'une autre 
fonction! Qui plus est celui d'une fonction trés différente sans aucun lien avec la 
nótre. Cependant elle posséde exactement le méme épilogue, probablement parce 
qu'elle accepte utilise elle aussi 5 variables locales (5 + 4 = 0214). 


De plus elle est située à une adresse proche. 


En réalité, peut importe l'épilogue qui est utilisé du moment que le fonctionnement 
est celui attendu. 


Il semble donc que le compilateur Keil décide de réutiliser à des fins d'économie un 
fragment d'une autre fonction. Notre épilogue aurait nécessité 4 octets. L'instruction 
de saut n'en utilise que 2. 


ARM + avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


Listing 1.350 : avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


var C = -0xC 


PUSH {R7,LR} 

MOV R7, SP 

SUB SP, SP, #4 

MOV R9, R1; b 

MOV R1, RO; a 

MOVW RO, #0xF10 ; "a=%d; b=%d; c=%d; d=%d\n" 
SXTB R1, Rl ; prepare a 

MOVT.W RO, #0 

STR R3, [SP,#0xC+var_C] ; place d to stack for printf() 
ADD RO, PC ; format-string 

SXTB R3, R2 ; prepare c 

MOV R2, R9 ; b 

BLX | printf 

ADD SP, SP, #4 

POP (R7,PC) 


OOANAUBWNE 
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SXTB (Signed Extend Byte) est similaire a MOVSX pour les architectures x86. Pour le 


reste—c’est identique. 


MIPS 
Listing 1.351 : avec optimisation GCC 4.4.5 (IDA) 
f: 
var_18 = -0x18 
var_10 = -0x10 
var_4 = -4 
arg 0 = 0 
arg 4 = 4 
arg 8 = 8 
arg C = 0xC 
; $a0-s.a 
; $al=s.b 
; $a2=S.C 
; $a3-s.d 
lui $gp, ( gnu local gp >> 16) 
addiu $sp, -0x28 
la $gp, (_ gnu local gp € OxFFFF) 
SW $ra, 0x28+var_4($sp) 
sw $gp, Ox28+var 10($sp) 
; Transformation d'un octet en entier 32 bits grand-boutien (big-endian): 
sra $t0, $a0, 24 
move $vl, $al 
; Transformation d'un entier 32 bits grand-boutien (big-endian) en octet: 
sra $v0, $a2, 24 
lw $t9, (printf € OxFFFF) ($gp) 
sw $a0, 0x28+arg_0($sp) 
lui $20, ($LCO >> 16) 4 "a=%d; b=%d; c=%d; d=%d\n" 
SW $a3, 0x28+var_18($sp) 
SW $al, 0x28+arg_4($sp) 
sw $a2, Ox28+arg 8($sp) 
SW $a3, Ox28+arg C($sp) 
la $a0, ($LCO € OXFFFF) # "a=%d; b=%d; c=%d; d=%d\n" 
move $al, $t0 
move $a2, $v1 
jalr $t9 
move $a3, $v0 ; Gaspillage volontaire du délai de 
branchement 
lw $ra, 0x28+var_4($5p) 
or $at, $zero ; Gaspillage par NOP du délai de 
chargement 
jr $ra 
addiu $sp, 0x28 ; Gaspillage volontaire du délai de 
branchement 
$LCO: .ascii "a=%d; b=%d; c=%d; d=%d\n"<0> 


Les champs de la structure sont fournis dans les registres $A0..$A3 puis transfor- 
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mé dans les registres $A1..$A3 pour l'utilisation par printf (), tandis que le 4ème 
champ (provenant de $A3) est passé sur la pile en utilisant l'instruction SW. 


Mais à quoi servent ces deux instructions SRA («Shift Word Right Arithmetic ») lors 
de la préparation des champs char ? 


MIPS est une architecture grand-boutien (big-endian) par défaut 2.2 on page 586, 
de méme que la distribution Debian Linux que nous utilisons. 


En conséquence, lorsqu'un octet est stocké dans un emplacement 32bits d'une struc- 
ture, ils occupent les bits 31..24 bits. 


Quand une variable char doit étre étendue en une valeur sur 32 bits, elle doit tout 
d'abord étre décalée vers la droite de 24 bits. 


char étant un type signé, un décalage arithmétique est utilisé ici, à la place d'un 
décalage logique. 


Un dernier mot 


Passer une structure comme argument d'une fonction (plutót que de passer un poin- 
teur sur cette structure) revient à passer chaque champ de la structure individuelle- 
ment. 


Si les champs de la structure utilisent l'alignement par défaut, la fonction f() peut 
étre réécrite ainsi: 


void f(char a, int b, char c, int d) 


1 
}; 


printf ("a=%d; b=%d; c=%d; d=%d\n", a, b, C, d); 


Le code généré par le compilateur sera le méme. 


1.30.5 Structures imbriquées 


Maintenant qu'en est-il lorsqu'une structure est définie au sein d'une autre struc- 
ture ? 


#include <stdio.h> 


struct inner struct 


1 
int a; 
int b; 
}; 
struct outer struct 
{ 
char a; 
int b; 
struct inner struct c; 
char d; 


int e; 
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}; 
void f(struct outer struct s) 
{ 
printf ("a=%d; b=%d; c.a=%d; c.b=%d; d=%d; e=%d\n", 
s.a, S.b, S.C.a, s.c.b, s.d, s.e); 
}; 
int main() 
{ 
struct outer struct s; 
s.a=1; 
s.b=2; 
s.c.a=100; 
s.c.b=101; 
s.d=3; 
s.e=4; 
f(s); 
}; 


...dans ce cas, l'ensemble des champs de inner struct doivent être situés entre 
les champs a,b et d,e de outer struct. 


Compilons (MSVC 2010) : 
Listing 1.352 : avec optimisation MSVC 2010 /ObO 


$SG2802 DB 'a=%d; b=%d; c.a=%d; c.b-*sd; d=%d; e-*sd', OaH, OOH 


_ TEXT SEGMENT 

_s$ = 8 

E PROC 
mov eax, DWORD PTR _s$[esp+16] 
movsx ecx, BYTE PTR _s$[esp+12] 
mov edx, DWORD PTR _s$[esp+8] 


push eax 

mov eax, DWORD PTR _s$[esp+8] 
push ecx 

mov ecx, DWORD PTR _s$[esp+8] 
push edx 

movsx edx, BYTE PTR _s$[esp+8] 
push eax 

push ecx 

push edx 


push OFFSET $5G2802 ; 'a=%d; b=%d; c.a=%d; c.b=%d; d=%d; e=%d' 
call printf 
add esp, 28 
ret 0 
f ENDP 


_s$ = -24 

_main PROC 
sub esp, 24 
push ebx 
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push 
push 
mov 
sub 
mov 
; depuis 
mov 
mov 
mov 
mov 
lea 
lea 
lea 
mov 
mov 
mov 
mov 
mov 
mov 
call 
add 
pop 
pop 
xor 
pop 
add 
ret 
main 


esi 
edi 
ecx, 2 
esp, 24 
eax, esp 

ce moment, EAX est synonyme de ESP: 
BYTE PTR s$[esp+60], 1 
ebx, DWORD PTR _s$[esp+60] 
DWORD PTR [eax], ebx 
DWORD PTR [eax+4], ecx 
edx, DWORD PTR [ecx+98] 
esi, DWORD PTR [ecx+99] 
edi, DWORD PTR [ecx+2] 
DWORD PTR [eax+8], edx 
BYTE PTR _s$[esp+76], 3 
ecx, DWORD PTR _s$[esp+76] 
DWORD PTR [eax+12], esi 
DWORD PTR [eax+16], ecx 
DWORD PTR [eax+20], edi 
T 
esp, 24 
edi 
esi 
eax, eax 
ebx 
esp, 24 
0 

ENDP 


Un point troublant est qu'en observant le code assembleur généré, nous n'avons 
aucun indice qui laisse penser qu'il existe une structure imbriquée! Nous pouvons 
donc dire que les structures imbriquées sont fusionnées avec leur conteneur pour 


former une seule structure /inear ou one-dimensional. 


Bien entendu, si nous remplacons la déclaration struct inner struct c; parstruct 
inner struct *c; (en introduisant donc un pointeur) la situation sera totalement 
différente. 
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OllyDbg 


Chargeons notre exemple dans OllyDbg et observons outer_struct en mémoire: 


CPU - main thread, module nested 


SS: [ARG.6] 
PTR LARG. 5] 
: LARG. 41 


ested. 00E73303 


DWORD PTR SS: CARG. 3] nested.00E75301 


DWORD PTR SS: CARG.2] ^ Ba29FESO 
n LARG. 11 98008865 
v aaaaaaa4 

> Ø0E71000 nested. D0E71000 
at FFFFFFFF) 
@( FFFFFFFF) 
BL FFFFFFFF) 
Bt FFFFFFFF) 
7EFODGG6( FFF) 
at FFFFFFFF) 


Fig. 1.107: OllyDbg : Avant appel de la fonction printf() 


Les valeurs sont organisées en mémoire de la maniére suivante: 
* (outer struct.a) (octet) 1 + 3 octets de détritus; 
* (outer struct.b) (mot de 32 bits) 2; 
* (inner struct.a) (mot de 32 bits) 0x64 (100); 
* (inner struct.b) (mot de 32 bits) 0x65 (101); 
* (outer struct.d) (octet) 3 + 3 octets de détritus; 
( 


* (outer struct.e) (mot de 32 bits) 4. 


1.30.6 Champs de bits dans une structure 
Exemple CPUID 


Le langage C/C++ permet de définir précisément le nombre de bits occupés par 
chaque champ d'une structure. Ceci est trés utile lorsque l'on cherche à économise 
de la place. Par exemple, chaque bit permet de représenter une variable bool. Bien 
entendu, c'est au détriment de la vitesse d'exécution. 


Prenons par exemple l'instruction CPUID!9!, Elle retourne des informations au sujet 
de la CPU qui exécute le programme et de ses capacités. 


16! Wikipédia 
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Si le registre EAX est positionné à la valeur 1 avant d'invoquer cette instruction, 
CPUID va retourné les informations suivantes dans le registre EAX : 


3:0 (4 bits) Stepping 

7:4 (4 bits) Modéle 

11:8 (4 bits) Famille 

13:12 (2 bits) | Type de processeur 
19:16 (4 bits) | Sous-modéle 

27:20 (8 bits) | Sous-famille 


MSVC 2010 fourni une macro CPUID, qui est absente de GCC 4.4.1. Tentons donc de 
rédiger nous méme cette fonction pour une utilisation dans GCC gráce à l'assem- 
bleur!6? intégré à ce compilateur. 


#include <stdio.h> 


#ifdef | GNUC _ 

static inline void cpuid(int code, int *a, int *b, int *c, int *d) { 
asm volatile("cpuid":"=a"(*a),"=b"(*b),"=c"(*c),"=d"(*d):"a"(code)); 

} 

#endif 


#ifdef _MSC_VER 
#include <intrin.h> 


#endif 

struct CPUID 1 EAX 

{ 
unsigned int stepping:4; 
unsigned int model:4; 
unsigned int family_id:4; 
unsigned int processor type:2; 
unsigned int reservedl:2; 
unsigned int extended model id:4; 
unsigned int extended family id:8; 
unsigned int reserved2:4; 

$; 

int main() 

1 
struct CPUID 1 EAX *tmp; 
int b[4]; 

#ifdef MSC VER 
__cpuid(b,1); 

#endif 


#ifdef | GNUC — 
cpuid (1, &b[0], &b[1], &b[2], &b[3]); 
#endif 


tmp=(struct CPUID 1 EAX *)&b[0]; 
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printf ("stepping=%d\n", tmp->stepping) ; 

printf ("model=%d\n", tmp->model) ; 

printf ("family_id=%d\n", tmp->family_id); 

printf ("processor type=%d\n", tmp->processor type); 

printf ("extended model id-*dWMn", tmp->extended model id); 
printf ("extended family id=%d\n", tmp->extended family id); 
return 0; 


Aprés que l'instruction CPUID ait rempli les registres EAX/EBX/ECX/EDX, ceux-ci doivent 
étre recopiés dans le tableau b[]. Nous affectons dont le pointeur de structure 
CPUID 1 EAX pour qu'il contienne l'adresse du tableau b[]. 


En d'autres termes, nous traitons une valeur int comme une structure, puis nous 
lisons des bits spécifiques de la structure. 


MSVC 


Compilons notre exemple avec MSVC 2008 en utilisant l'option /0x : 


Listing 1.353 : avec optimisation MSVC 2008 


_b$ = -16 ; size = 16 

_Main PROC 
sub esp, 16 
push ebx 
xor ecx, ecx 
mov eax, 1 
cpuid 
push esi 
lea esi, DWORD PTR _b$[esp+24] 
mov DWORD PTR [esi], eax 
mov DWORD PTR [esi+4], ebx 
mov DWORD PTR [esi+8], ecx 
mov DWORD PTR [esi+12], edx 
mov esi, DWORD PTR _b$[esp+24] 
mov eax, esi 
and eax, 15 
push eax 
push OFFSET $S5G15435 ; 'stepping-*d', 0aH, 00H 
call printf 
mov ecx, esi 
shr ecx, 4 
and ecx, 15 
push ecx 
push OFFSET $5G15436 ; 'model=%d', O0aH, 00H 
call printf 
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mov 
shr 
and 
push 
push 
call 


mov 
shr 
and 
push 
push 
call 


mov 
shr 
and 
push 
push 
call 


shr 
and 
push 
push 
call 
add 


pop 


xor 
pop 


add 
ret 
_main 


edx, esi 
edx, 8 
edx, 15 
edx 


OFFSET $56G15437 ; 


| printf 


eax, esi 
eax, 12 
eax, 3 
eax 


OFFSET $5615438 ; 


| printf 


ecx, esi 
ecx, 16 
ecx, 15 
ecx 


OFFSET $5615439 ; 


| printf 


esi, 20 
esi, 255 
esi 


OFFSET $5G15440 ; 


| printf 
esp, 48 
esi 


eax, eax 
ebx 


esp, 16 
0 


ENDP 


, 


, 


, 


, 


‘family id=%d', OaH, OOH 


‘processor type=%d', OaH, 00H 


‘extended model id=%d', OaH, OOH 


‘extended family id=%d', OaH, 00H 


L'instruction SHR va décaler la valeur du registre EAX d'un certain nombre de bits qui 
vont étre abandonnées. Nous ignorons donc certains des bits de la partie droite. 


L'instruction AND "efface" les bits inutiles sur la gauche, ou en d'autres termes, ne 
laisse dans le registre EAX que les bits qui nous intéressent. 
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MSVC + OllyDbg 


Chargeons notre exemple dans OllyDbg et voyons quelles valeurs sont présentes 
dans EAX/EBX/ECX/EDX aprés exécution de l'instruction CPUID: 


PUSH EBX 
3309 XOR ECX, ECX 
BS 01000008 | MOV EAX, 1 
BFAZ CPUID 


56 PUSH ESI 
807424 a8 [LEA ESI, (LOCAL. 31 
8906 NOU DWORD PTR DS: CESI], EAX 
MOU DWORD PTR DS: CESI+4), EBX 
MOU DWORD PTR DS: LES1+81,ECX MNT: 
MOU DWORD PTR DS: CESI+0C), EDX ). 90401000 
NOU ESI, DUORD PTR SS: CLOCAL. 33 ca jit QUFFFFFFFF) 
AND EAX, G00000F iv Te CBLEEEEEEEES 
PUSH ERA , jit BtFFFFFFFF) 

= G VEFODGGG( FFF) 

OC FFFFFFFF) 


SUCCESS 
S,PE,GE,LE) ¡e 


RETURN from CPU 


| Address [Hex dump — — ^ 1 —  — ASCII (ausi 
CEEI ES 74 7 SE 5 BA OA E 
6D 6F 
RETURN from CPU 
RETURN from CPU 


Fig. 1.108: OllyDbg : Aprés exécution de CPUID 


La valeur de EAX est 0x000206A7 (ma CPU est un Intel Xeon E3-1220). 
Cette valeur exprimée en binaire vaut 0200000000000000100000011010100111. 


Voici la maniére dont les bits sont répartis sur les différents champs: 


champ format binaire | format décimal 
reserved2 0000 0 
extended family id | 00000000 0 
extended model id | 0010 2 
reservedl 00 0 
processor_id 00 0 
family_id 0110 6 
model 1010 10 
stepping 0111 7 
Listing 1.354 : Console output 

stepping-7 

model-10 

family id-6 


processor type-0 
extended model id-2 
extended family id-0 
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GCC 


Essayons maintenant une compilation avec GCC 4.4.1 en utilisant l'option -03. 


Listing 1.355 : avec optimisation GCC 4.4.1 


main 

push 
mov 
and 
push 
mov 
push 
mov 
sub 
cpuid 
mov 
and 
mov 
mov 
mov 
call 
mov 
shr 
and 
mov 
mov 
mov 
call 
mov 
shr 
and 
mov 
mov 
mov 
call 
mov 
shr 
and 
mov 
mov 
mov 
call 
mov 
shr 
shr 
and 
and 
mov 
mov 


proc near ; DATA XREF: start+17 
ebp 
ebp, esp 
esp, OFFFFFFFOh 
esi 
esi, 1 
ebx 
eax, esi 
esp, 18h 


esi, eax 

eax, OFh 

[esp+8], eax 

dword ptr [esp+4], offset aSteppingD ; 
dword ptr [esp], 1 

|. printf chk 

eax, esi 

eax, 4 

eax, OFh 

[esp+8], eax 

dword ptr [esp+4], offset aModelD ; 
dword ptr [esp], 1 

|. printf chk 

eax, esi 

eax, 8 

eax, OFh 

[esp+8], eax 

dword ptr [esp+4], offset aFamily idD ; "family id=%d\n" 
dword ptr [esp], 1 

|. printf chk 

eax, esi 

eax, OCh 

eax, 3 

[esp+8], eax 

dword ptr [esp+4], offset aProcessor type ; 
dword ptr [esp], 1 

|. printf chk 

eax, esi 

eax, 10h 

esi, 14h 

eax, OFh 

esi, OFFh 

[esp+8], eax 

dword ptr [esp+4], offset aExtended model ; 


"stepping=%d\n" 


"model=%d1n" 


"processor type=%d\n" 


"extended model id=%d\n" 


mov 
call 
mov 


dword ptr [esp], 1 
|. printf chk 
[esp+8], esi 
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mov dword ptr [esp+4], offset unk 80486D0 
mov dword ptr [esp], 1 
call |. printf chk 
add esp, 18h 
xor eax, eax 
pop ebx 
pop esi 
mov esp, ebp 
pop ebp 
retn 
main endp 


Le résultat est quasiment identique. Le seul élément notable est que GCC combine 
en quelques sortes le calcul de extended model id et extended family id en un 
seul bloc au lieu de les calculer séparément avant chaque appel à printf(). 


Travailler avec le type float comme une structure 


Comme nous l'avons expliqué dans la section traitant de la FPU (1.25 on page 285), 
les types float et double sont constitués d'un signe, d'un significande (ou fraction) et 
d'un exposant. Mais serions nous capable de travailler avec chacun de ces champs 
indépendamment? Essayons avec un float. 


3130 2322 0 


S| exposant mantisse ou fraction 


( S — signe) 


#include <stdio.h> 
#include <assert.h> 
#include <stdlib.h> 
#include <memory.h> 


struct float_as struct 


{ 
unsigned int fraction : 23; // fraction 
unsigned int exponent : 8; // exposant + Ox3FF 
unsigned int sign : 1; // bit de signe 

$; 


float f(float _in) 
1 


float f- in; 
struct float as struct t; 
assert (sizeof (struct float as struct) -- sizeof (float)); 


memcpy (&t, &f, sizeof (float)); 


t.sign=1; // Positionnons le bit de signe 
t.exponent=t.exponent+2; // multiplions d par 2"(n vaut 2 ici) 
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memcpy (&f, 


&t, sizeof (float)); 


printf ("%f\n", f(1.234)); 


return f; 
}; 
int main() 
{ 
}; 


La structure float as struct occupe le méme espace qu'un float, soit 4 octets ou 


32 bits. 


Nous positionnons maintenant le signe pour qu'il soit négatif puis en ajoutant à la 
valeur de l'exposant, ce qui fait que nous multiplions le nombre par 2°, soit 4. 


Compilons notre exemple avec MSVC 2008, sans optimisation: 


Listing 1.356 : MSVC 2008 sans optimisation 


_t$ = -8 ; Size = 4 
_f$ = -4 ; Size = 4 
__in$ = 8 ; size = 4 
?F@@YAMM@Z PROC ; f 
push ebp 
mov ebp, esp 
sub esp, 8 
fld DWORD PTR __in$[ebpl] 
fstp DWORD PTR f$[ebp] 
push 4 
lea eax, DWORD PTR  f$[ebp] 
push eax 
lea ecx, DWORD PTR  t$[ebp] 
push ecx 
call | memcpy 
add esp, 12 
mov edx, DWORD PTR t$[ebp] 
or edx, -2147483648 ; 80000000H 
mov DWORD PTR t$[ebp], edx 
mov eax, DWORD PTR t$[ebp] 
shr eax, 23 ; 00000017H 
and eax, 255 ; 000000ffH 
l'exposant 
add eax, 2 ; ajouter 2 
and eax, 255 ; 000000ffH 
shl eax, 23 ; 00000017H 
les bits 30:23 
mov ecx, DWORD PTR t$[ebp] 
and ecx, -2139095041 ; 807fffffH 


positionnement du site négatif 


suppression du signifiant 
nous ne conservons ici que 


décalage du résultat pour supprimer 


suppression de l'exposant 
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; ajout de la valeur originale de l'exposant avec le nouvel exposant qui 
vient d'étre calculé: 
or i 


mov DWORD PTR t$[ebp], ecx 


push 4 

lea edx, DWORD PTR _t$[ebp] 
push edx 

lea eax, DWORD PTR f$[ebp] 
push eax 

call memcpy 


add esp, 12 


fld DWORD PTR _f$[ebp] 


mov esp, ebp 

pop ebp 

ret 0 
?f@@YAMM@Z ENDP of 


Si nous avions compilé avec le flag /0x il n'y aurait pas d'appel à la fonction memcpy (), 
et la variable f serait utilisée directement. Mais la compréhension est facilitée lorsque 
l'on s'intéresse à la version non optimisée. 


A quoi cela ressemblerait si nous utilisions l'option -03 avec le compilateur GCC 
4.4.1? 


Listing 1.357 : GCC 4.4.1 avec optimisation 


; f(float) 
public _Z1ff 
_Z1ff proc near 


var 4 = dword ptr -4 


arg_0 dword ptr 8 
push ebp 
mov ebp, esp 
sub esp, 4 
mov eax, [ebp+arg 0] 
or eax, 80000000h ; positionnement du signe négatif 
mov edx, eax 
and eax, 807FFFFFh ; Nous ne conservons que le signe et le 
signifiant dans EAX 
shr edx, 23 ; Préparation de l'exposant 
add edx, 2 ; Ajout de 2 


movzx edx, dl RAZ de tous les octets dans EDX à 


l'exception des bits 7:0 


shl edx, 23 ; Décalage du nouvel exposant pour qu'ils soit 
à sa place 

or eax, edx ; Consolidation du nouvel exposant et de la 
valeur originale de l'exposant 

mov [ebp+var 4], eax 

fld [ebp+var_4] 


leave 
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retn 
_Z1ff endp 


public main 
main proc near 


push ebp 

mov ebp, esp 

and esp, OFFFFFFFOh 

sub esp, 10h 

fld ds:dword 8048614 ; -4.936 
fstp qword ptr [esp+8] 

mov dword ptr [esp+4], offset asc 8048610 ; "%f\n" 
mov dword ptr [esp], 1 

call .. printf chk 

xor eax, eax 

leave 

retn 


main | endp 


La fonction f() est à peu prés compréhensible. Par contre ce qui est intéressant 
c'est que GCC a été capable de calculer le résultat de f(1.234) durant la compila- 
tion malgré tous les triturages des champs de la structure et a directement préparé 
l'argument passé a printf() durant la compilation! 


1.30.7 Exercices 


* http://challenges.re/71 
* http://challenges.re/72 


1.31 Le bogue struct classique 


Ceci est un bogue struct classique 
Voici un exemple de définition: 


struct test 
1 
int fieldl; 
int field2; 
}; 


Et puis les fichiers C: 


void setter(struct test *t, int a, int b) 
1 
t->fieldl=a; 
t->field2=b; 
}; 
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#include <stdio.h> 


void printer(struct test *t) 
{ 
printf ("%d\n", t->field1); 
printf ("%d\n", t->field2); 
}; 


Jusqu'ici, tout va bien. 


Maintenant vous ajoutez un troisième champ dans la structure, entre les deux champs: 


struct test 


{ 
int fieldl; 
int inserted; 
int field2; 
}; 


Et vous modifiez probablement la fonction setter(), mais oubliez printer() : 


void setter(struct test *t, int a, int b, int c) 


1 
t->fieldl=a; 
t->inserted=b; 
t->field2=c; 
}; 


Vous compilez votre projet, mais le fichier C où se trouve printer() qui est séparé, 
n'est pas recompilé car votre IDE?®? ou système de compilation n'a pas d'idée que ce 
module dépend d'une définition de structure test. Peut-être car #include <new.h> 
est oublié. Ou peut-être que le fichier d'entéte new.h est inclus dans printer.c 
via un autre fichier d'entéte. Le fichier objet n'est pas modifié (l'IDE pense qu'il n'a 
pas besoin d'étre recompilé), tandis que la fonction setter() est déjà la nouvelle 
version. Ces deux fichiers objets (ancien et nouveau) peuvent tót ou tard étre liés 
dans un fichier exécutable. 


Ensuite, vous le lancez, et le setter() met les 3 champs aux offsets +0, +4 et +8. 
Toutefois. printer() connait seulement 2 champs, et les prends aux offsets +0 et 
+4 lors de l'affichage. 


Ceci conduits a des bogues obscurs et méchants. La raison est que l'IDE ou le sys- 
téme de construction ou le Makefile ne savent pas que les deux fichiers C (ou mo- 
dules) dépendent de l'entéte. Un reméde courant est de tout supprimer et de recom- 
piler. 


Ceci est également vrai pour les classes C++, puisqu'elles fonctionnent tout comme 
des structures: 3.21.1 on page 698. 


Ceci est une maladie ce C/C++, et une source de critique, oui. De nombreux LPs ont 
un meilleur support des modules et interfaces. Mais gardez à l'esprit l'époque de 
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création du ocmpilateur C: dans les années 70, sur de vieux ordinateurs PDP. Donc 
tout a été simplifié a ceci par les créateurs du C. 


1.32 Unions 


Les unions en C/C++ sont utilisées principalement pour interpréter une variable (ou 
un bloc de mémoire) d'un type de données comme une variable d'un autre type de 
données. 


1.32.1 Exemple de générateur de nombres pseudo-aléatoires 


Si nous avons besoin de nombres aléatoires a virgule flottante entre O et 1, le plus 
simple est d'utiliser un PRNG comme le Twister de Mersenne. Il produit une valeur 
aléatoire non signée sur 32-bit (en d'autres mots, il produit une valeur 32-bit aléa- 
toire). Puis, nous pouvons transformer cette valeur en float et le diviser par RAND MAX 
(OxFFFFFFFF dans notre cas)—nous obtenons une valeur dans l'intervalle O..1. 


Mais nous savons que la division est lente. Aussi, nous aimerions utiliser le moins 
d'opérations FPU possible. Peut-on se passer de la division? 


Rappelons-nous en quoi consiste un nombre en virgule flottante: un bit de signe, 
un significande et un exposant. Nous n'avons qu'à stocker des bits aléatoires dans 
toute le significande pour obtenir un nombre réel aléatoire! 


L'exposant ne peut pas étre zéro (le nombre flottant est dénormalisé dans ce cas), 
donc nous stockons 0b01111111 dans l'exposant—ce qui signifie que l'exposant est 
1. Ensuite nous remplissons le significande avec des bits aléatoires, mettons le signe 
à 0 (ce qui indique un nombre positif) et voilà. Les nombres générés sont entre 1 et 
2, donc nous devons soustraire 1. 


Un générateur congruentiel linéaire de nombres aléatoire trés simple est utilisé dans 
mon exemple!9 , il produit des nombres 32-bit. Le PRNG est initialisé avec le temps 
courant au format UNIX timestamp. 


Ici, nous représentons un type float comme une union—c'est la construction C/C++ 
qui nous permet d'interpréter un bloc de mémoire sous différents types. Dans notre 
Cas, nous pouvons créer une variable de type union et y accéder comme si c'est un 
float ou un uint32 t. On peut dire que c'est juste un hack. Un sale. 


Le code du PRNG entier est le méme que celui que nous avons déjà considéré: 1.29 
on page 436. Donc la forme compilée du code est omise. 


#include <stdio.h> 
#include <stdint.h> 
#include <time.h> 


// PRNG entier définitions, données et routines: 


// constantes provenant du livre Numerical Recipes 
const uint32 t RNG_a=1664525; 


164l'idée a été prise de: URL 
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const uint32 t RNG c-1013904223; 
uint32 t RNG state; // variable globale 


void my srand(uint32 t i) 


RNG state-i; 


uint32 t my rand() 
RNG state-RNG state*RNG a+RNG c; 
return RNG state; 

}; 

// PRNG FPU définitions et routines: 


union uint32 t float 


1 
uint32 t i; 
float f; 
}; 
float float rand() 
1 
union uint32 t float tmp; 
tmp.i-my rand() € 0x007fffff | Ox3F800000; 
return tmp.f-1; 
}; 
// test 
int main() 
1 
my srand(time(NULL)); // initialisation du PRNG 
for (int i20; i«100; i++) 
printf ("%f\n", float rand()); 
return 0; 
}; 
x86 
Listing 1.358 : MSVC 2010 avec optimisation 
$SG4238 DB 'SSf', OaH, OOH 
. reale3ff0000000000000 DQ 03ff0000000000000r ; 1 
tv130 = -4 
_tmp$ = -4 


?float_rand@@YAMXZ PROC 
push ecx 
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call ?my_rand@@YAIXZ 
; EAX=valeur pseudo-aléatoire 

and eax, 8388607 ; 007fffffH 

or eax, 1065353216 ; 3f800000H 
; EAX=valeur pseudo-aléatoire € 0x007fffff | Ox3f800000 
la stocker dans la pile locale: 


mov DWORD PTR _tmp$[esp+4], eax 
; la recharger en tant que nombre à virgule flottante: 
fld DWORD PTR tmp$[esp+4] 


soustraire 1.0: 

fsub QWORD PTR  realq3ff0000000000000 
stocker la valeur obtenue dans la pile locale et la recharger: 
ces instructions sont redondantes: 

fstp DWORD PTR tv130[esp+4] 


fld DWORD PTR tv130[esp+4] 
pop ecx 
ret 0 


?float_rand@@YAMXZ ENDP 


main PROC 
push esi 
xor eax, eax 
call time 
push eax 
call ?my_srand@@YAXI@Z 
add esp, 4 
mov esi, 100 
$LL3@main: 
call ?float rand@@YAMXZ 
sub esp, 8 


fstp QWORD PTR [esp] 
push OFFSET $5G4238 


call _printf 
add esp, 12 
dec esi 
jne SHORT $LL3@main 
xor eax, eax 
pop esi 
ret 0 
main  ENDP 


Les noms de fonctions sont étranges ici car cet exemple a été compilé en tant que 
C++ et ceci est la modification des noms en C++, nous en parlerons plus loin: 3.21.1 
on page 699. Si nous compilons ceci avec MSVC 2012, il utilise des instructions SIMD 
pour le FPU, pour en savoir plus: 1.38.5 on page 567. 


ARM (Mode ARM) 


Listing 1.359 : GCC 4.6.3 avec optimisation (IDA) 


float rand 
STMFD SP!, {R3,LR} 
BL my rand 


489 


RO-valeur pseudo-aléatoire 
FLDS S0, -1.0 


; S0=1.0 
BIC R3, RO, #0xFF000000 
BIC R3, R3, #0x800000 
ORR R3, R3, #0x3F800000 
; R3=valeur pseudo-aléatoire & 0x007fffff | 0x3f800000 
copier de R3 vers FPU (registre S15). 
; Ca se comporte comme une copie bit à bit, pas de conversion faite: 
FMSR S15, R3 
soustraire 1.0 et laisser le résultat dans S0: 
FSUBS S0, S15, SO 
LDMFD SP!, {R3,PC} 


flt 5C DCFS 1.0 
main 
STMFD SP!, {R4,LR} 
MOV RO, 40 
BL time 
BL my srand 
MOV R4, 40x64 ; 'd' 
loc 78 
BL float rand 
; SO0-valeur pseudo-aléatoire 
LDR RO, -aF ; "Sf" 


; convertir la valeur obtenue en type double (printf() en a besoin): 
FCVTDS D7, SO 

; copie bit à bit de D7 dans la paire de registres R2/R3 (pour printf()): 
FMRRD R2, R3, D7 


BL printf 
SUBS R4, R4, #1 
BNE loc 78 
MOV RO, R4 


LDMFD — SP!, {R4,PC} 


aF DCB "%f",0xA,0 


Nous allons faire un dump avec objdump et nous allons voir que les instructions 
FPU ont un nom différent que dans IDA. Apparemment, les développeurs de IDA et 
binutils ont utilisés des manuels différents? Peut-étre qu'il serait bon de connaítre 
les deux variantes de noms des instructions. 


Listing 1.360 : GCC 4.6.3 avec optimisation (objdump) 


00000038 <float_rand>: 


38: e92d4008 push (r3, lr} 

3c: ebfffffe bl 10 «my rand» 

40: | ed9f0a05 vldr s0, [pc, #20] ; 5c <float_rand+0x24> 
44: e3c034ff bic r3, r0, #-16777216 ; Oxff000000 
48: e3c33502 bic r3, r3, #8388608 ; 0x800000 

4c: e38335fe orr r3, r3, #1065353216 ; 0x3f800000 


50: ee073a90 vmov s15, r3 
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54: ee370ac0 vsub.f32 s0, s15, sO 
58: e8bd8008 pop {r3, pc} 
5c: 31800000 SVCCC 0x00800000 
00000000 «main»: 

0: e92d4010 push (r4, lr} 

4: e3a00000 mov ro, #0 

8: ebfffffe bl 0 «time» 

C: ebfffffe bl 0 «main» 

10: e3a04064 mov r4, #100 ; 0x64 
14: ebfffffe bl 38 <main+0x38> 

18: e59f0018 ldr ro, [pc, #24] ; 38 <main+0x38> 
1c: eeb77ac0 vcvt.f64.f32 d7, s0 
20: ec532b17 vmov r2, r3, d7 
24: ebfffffe bl 0 <printf> 
28: e2544001 subs r4, r4, #1 
2c: lafffff8 bne 14 <main+0x14> 
30: ela00004 mov ro, r4 
34: e8bd8010 pop {r4, pc} 
38: 00000000 andeq ro, rO, ro 


Les instructions en Ox5c dans float rand() et en 0x38 dans main() sont du bruit 


(pseudo-)aléatoire. 


1.32.2 Calcul de l'epsilon de la machine 


L’epsilon de la machine est la plus petite valeur avec laquelle le FPU peut travailler. 
Plus il y a de bits alloués pour représenter un nombre en virgule flottante, plus l'ep- 
silon est petit, C'est 27” 4 1.19e - 07 pour les float et 27%? x 2.22e - 16 pour les double. 


Voir aussi: l'article de Wikipédia. 


Il intéressant de voir comme il est facile de calculer l'epsilon de la machine: 


#include <stdio.h> 
#include <stdint.h> 


union uint float 

1 
uint32 t i; 
float f; 

}; 


float calculate machine epsilon(float start) 
{ 
union uint float v; 
v.f=start; 
V.i++: 
return v.f-start; 


} 


void main() 


{ 


printf ("%g\n", calculate machine epsilon(1.0)); 
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Ce que l'on fait ici est simplement de traiter la partie fractionnaire du nombre au 
format IEEE 754 comme un entier et de lui ajouter 1. Le nombre flottant en résultant 
est égal à starting value--machine epsilon, donc il suffit de soustraire starting value (en 
utilisant l'arithmétique flottante) pour mesurer ce que la différence d'un bit repré- 
sente dans un nombre flottant simple précision(float). L' union permet ici d'accéder 
au nombre IEEE 754 comme à un entier normal. Lui ajouter 1 ajoute en fait 1 au 
significande du nombre, toutefois, inutile de dire, un débordement est possible, qui 
ajouterait 1 à l'exposant. 


x86 
Listing 1.361 : avec optimisation MSVC 2010 

tv130 = 8 
_v$ = 8 
_start$ = 8 
Calculate machine epsilon PROC 

fld DWORD PTR start$[esp-4] 
; cette instruction est redondante: 

fst DWORD PTR v$[esp-4] 

inc DWORD PTR v$[esp-4] 


fsubr DWORD PTR v$[esp-4] 
; cette paire d'instructions est aussi redondante: 
fstp DWORD PTR tv130[esp-4] 
fld DWORD PTR tv130[esp-4] 
ret 0 
calculate machine epsilon ENDP 


La seconde instruction FST est redondante: il n'est pas nécessaire de stocker la va- 
leur en entrée à la méme place (le compilateur a décidé d'allouer la variable v à la 
méme place dans la pile locale que l'argument en entrée). Puis elle est incrémen- 
tée avec INC, puisque c'est une variable entiére normale. Ensuite elle est chargée 
dans le FPU comme un nombre IEEE 754 32-bit, FSUBR fait le reste du travail et la 
valeur résultante est stockée dans STO. La derniére paire d'instructions FSTP/FLD est 
redondante, mais le compilateur n'a pas optimisé le code. 


ARM64 


Étendons notre exemple à 64-bit: 


#include <stdio.h> 
#include <stdint.h> 


typedef union 

{ 
uint64 t i; 
double d; 

} uint_double; 
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double calculate machine epsilon(double start) 


1 
uint double v; 
v.d=start; 
V.i++: 
return v.d-start; 
} 
void main() 
1 
printf ("%g\n", calculate machine epsilon(1.0)); 
$; 


ARM64 n'a pas d'instruction qui peut ajouter un nombre a un D-registre FPU, donc 
la valeur en entrée (qui provient du registre x64 DO) est d'abord copiée dans le GPR, 
incrémentée, copiée dans le registre FPU D1, et puis la soustraction est faite. 


Listing 1.362 : GCC 4.9 ARM64 avec optimisation 


calculate machine epsilon: 


fmov x0, dO ; charger la valeur d'entrée de type double dans 
X0 

add x0, x0, 1 ; XO++ 

fmov dl, x0 ; la déplacer dans le registre du FPU 

fsub dO, d1, dO ; Soustraire 

ret 


Voir aussi cet exemple compilé pour x64 avec instructions SIMD: 1.38.4 on page 566. 


MIPS 


Il y a ici la nouvelle instruction MTC1 («Move To Coprocessor 1»), elle transfére sim- 
plement des données vers les registres du FPU. 


Listing 1.363 : GCC 4.4.5 avec optimisation (IDA) 


calculate machine epsilon: 
mfcl $v0, $f12 
or gat, $zero ; NOP 
addiu $vl, $v0, 1 
mtcl $vl, $f2 
jr $ra 
sub.s $f0, $f2, $f12 ; branch delay slot 


Conclusion 


Il est difficile de dire si quelqu'un pourrait avoir besoin de cette astuce dans du code 
réel, mais comme cela a été mentionné plusieurs fois dans ce livre, cet exemple est 
utile pour expliquer le format IEEE 754 et les unions en C/C++. 
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1.32.3 Remplacement de FSCALE 


Agner Fog dans son travail! Optimizing subroutines in assembly language / An op- 
timization guide for x86 platforms indique que l'instruction FPU FSCALE (qui calcule 
2") peut étre lente sur de nombreux CPUs, et propose un remplacement plus rapide. 


Voici ma conversion de son code assembleur en C/C++ : 


#include <stdint.h> 
#include <stdio.h> 


union uint float 


1 
uint32 t i; 
float f; 

}; 

float flt 2n(int N) 

1 
union uint float tmp; 
tmp .i=(N<<23)+0x3f800000; 
return tmp.f; 

}; 

struct float as struct 

{ 
unsigned int fraction : 23; 
unsigned int exponent : 8; 
unsigned int sign : 1; 

}; 

float flt 2n v2(int N) 

1 
struct float as struct tmp; 
tmp.fraction=0; 
tmp.sign=0; 
tmp .exponent=N+0x7f; 
return *(float*)(&tmp); 

}; 

union uint64 double 

{ 
uint64 t i; 
double d; 

}; 

double dbl 2n(int N) 

1 


union uint64 double tmp; 


tmp.i-((uint64 t)N<<52)+0x3ff0000000000000UL; 


l65http://www.agner.org/optimize/optimizing assembly.pdf 
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return tmp.d; 


}; 
struct double as struct 
1 
uint64 t fraction : 52; 
int exponent : 11; 
int sign : 1; 
}; 
double dbl 2n v2(int N) 
1 
struct double as struct tmp; 
tmp.fraction=0; 
tmp.sign=0; 
tmp .exponent=N+0x3ff; 
return *(double*)(&tmp); 
}; 
int main() 
1 
// 2% = 2048 
printf ("%f\n", flt 2n(11)); 
printf ("%f\n", flt 2n v2(11)); 
printf ("%lf\n", dbl 2n(11)); 
printf ("%lf\n", dbl 2n v2(11)); 
F; 


L'instruction FSCALE peut être plus rapide dans votre environnement, mais néan- 
moins, c'est un bon exemple d'union et du fait que l'exposant est stocké sous la 
forme 2”, donc une valeur n en entrée est décalée a l'exposant dans le nombre en- 
codé en IEEE 754. Ensuite, l'exposant est corrigé avec l'ajout de 0x3f800000 ou de 
0x3ff0000000000000. 


La méme chose peut étre faite sans décalage utilisant struct, mais en interne, l'opé- 
ration de décalage aura toujours lieu. 


1.32.4 Calcul rapide de racine carré 


Un autre algorithme connu oü un float est interprété comme un entier est celui de 
calcul rapide de racine carrée. 


Listing 1.364 : Le code source provient de Wikipédia: https://en.wikipedia.org/ 
wiki/Methods of computing square roots 


/* Assumes that float is in the IEEE 754 single precision floating point ^7 
& format 
* and that int is 32 bits. */ 
float sqrt approx(float z) 


int val int = *(int*)&z; /* Same bits, but as an int */ 
/* 
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* To justify the following code, prove that 
* 


* ((((val_int / 2%m) - b) / 2) + b) * 2%m = ((val int - 27m) / 2) + ((7 
Gb + 1) / 2) * 27m) 

* 

* where 

* 

* b = exponent bias 

* m = number of mantissa bits 

* 

* . 

*/ 


val int -= 1 << 23; /* Subtract 2^m. */ 
val int »»- 1; /* Divide by 2. */ 
val int += 1 << 29; /* Add ((b + 1) / 2) * 2^m. */ 


return *(float*)&val int; /* Interpret again as float */ 


À titre d'exercice, vous pouvez essayez de compiler cette fonction et de comprendre 
comme elle fonctionne. 


C'est un algorithme connu de calcul rapide de Ta L'algorithme devint connu, sup- 


posément, car il a été utilisé dans Quake III Arena. 


La description de l'algorithme peut être trouvée sur Wikipédia: http: //en.wikipedia. 
org/wiki/Fast inverse square root. 


1.33 Pointeurs sur des fonctions 
Un pointeur sur une fonction, comme tout autre pointeur, est juste l'adresse de début 
de la fonction dans son segment de code. 
Ils sont souvent utilisés pour appeler des fonctions callback (de rappel). 
Des exemples bien connus sont: 
* qsort(), atexit() de la bibliothéque C standard; 
* signaux des OS *NIX; 
* démarrage de thread: CreateThread() (win32), pthread create() (POSIX); 


beaucoup de fonctions win32, comme EnumChildWindows(). 


* dans de nombreux endroits du noyau Linux, par exemple les fonctions des dri- 
vers du systéme de fichier sont appelées via callbacks. 


* Les fonctions des plugins GCC sont aussi appelées via callbacks. 


Donc, la fonction qsort() est une implémentation du tri rapide dans la bibliothéque 
standard C/C++. La fonction est capable de trier n'importe quoi, tout type de don- 
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nées, tant que vous avez une fonction pour comparer deux éléments et que qsort() 
est capable de l'appeler. 


La fonction de comparaison peut étre définie comme: 


int (*compare)(const void *, const void *) 


Utilisons l'exemple suivant: 


/* ex3 Sorting ints with qsort */ 


#include <stdio.h> 
#include <stdlib.h> 


int comp(const void * _a, const void * b) 
{ 
const int *a=(const int *) a; 
const int *b=(const int *) b; 


if (*a==*b) 
return 0; 
else 
if (*a « *b) 
return -1; 
else 
return 1; 


} 


int main(int argc, char* argv[]) 

{ 
int numbers[10]={1892,45,200, -98,4087,5, -12345,1087, 88, -100000}; 
int i; 


/* Sort the array */ 
qsort(numbers,10,sizeof(int),comp) ; 
for (i=0;i<9; i++) 

printf("Number = %d\n",numbers[ i ]) ; 
return 0; 


1.33.1 MSVC 


Compilons le dans MSVC 2010 (certaines parties ont été omises, dans un but de 
concision) avec l'option /0x : 


Listing 1.365 : MSVC 2010 avec optimisation : /GS- /MD 


| a$ = 8 ; size = 4 
__b$ = 12 ; size = 4 
comp PROC 

mov eax, DWORD PTR  a$[esp-4] 

mov ecx, DWORD PTR  b$[esp-4] 


mov eax, DWORD PTR [eax] 
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mov 
cmp 
jne 
xor 
ret 

$LN4@comp: 
xor 
cmp 
setge 
lea 
ret 

_comp ENDP 


_numbers$ = -40 
_argc$ = 8 
_argv$ = 12 
_main PROC 
sub 
push 
push 
push 
lea 
push 
push 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
call 
add 


ecx, DWORD PTR [ecx] 


eax, 


ecx 


SHORT $LN4@comp 


eax, 


esp, 
esi 


eax 


edx 
ecx 


DWORD PTR [edx+edx-1] 


40 


OFFSET _comp 


4 


eax, DWORD PTR _numbers$[esp+52] 


10 
eax 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
_qsor 
esp, 


PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 

t 

16 


_numbers$[esp+60] , 
_numbers$[esp+64], 
 numbers$[esp-468], 
_numbers$[esp+72], 
_numbers$[esp+76], 
_numbers$[esp+80], 
_numbers$[esp+84], 
_numbers$[esp+88], 
_numbers$[esp+92], 
_numbers$[esp+96], 


1892 

45 

200 

-98 
4087 

5 
-12345 
1087 

88 

- 100000 


size 
size 
size 


ou Il 
Az 


00000028H 


0000000aH 


00000764H 
0000002dH 
000000c8H 
ffffff9eH 
00000f f 7H 


ffffcfc/H 
0000043 fH 
00000058H 
fffe7960H 


00000010H 


Rien de surprenant jusqu'ici. Comme quatrieme argument, l'adresse du label comp 
est passée, qui est juste l'endroit ou se trouve comp( ), ou, en d'autres mots, l'adresse 


de la premiére instruction de cette fonction. 


Comment est-ce que qsort() l'appelle? 


Regardons cette fonction, située dans MSVCR80.DLL (un module DLL de MSVC avec 


des fonctions de la bibliothéque C standard) : 


Listing 1.366 : MSVCR80.DLL 


| .text:7816CBFO ; void 


. text: 7816CBFO 


.text:7816CBF0 _qsort 


cdecl qsort(void *, unsigned int, unsigned int, int 
cdecl *) (const void *, const void *)) 


public _qsort 
proc near 
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. text: 7816CBFO 

. text: 7816CBFO lo 
.text:7816CBF0 hi 

. text: 7816CBFO var FC 
.text:7816CBFO stkptr 
.text:7816CBFO lostk 
. text: 7816CBFO histk 
. text: 7816CBFO base 

. text: 7816CBFO num 
.text:7816CBFO width 
.text:7816CBFO comp 

. text: 7816CBFO 


dword ptr -104h 
dword ptr -100h 
dword ptr -OFCh 
dword ptr -OF8h 
dword ptr -OF4h 
dword ptr -7Ch 
dword ptr 4 

dword ptr 8 

dword ptr (Ch 
dword ptr 10h 


.text:7816CBF0 sub esp, 100h 
.text:7816CCEO loc 7816CCE0: ; CODE XREF: _qsort+Bl 
. text: 7816CCEO shr eax, 1 

. text: 7816CCE2 imul eax, ebp 
.text:7816CCE5 add eax, ebx 
.text:7816CCE7 mov edi, eax 

. text: 7816CCE9 push edi 

. text: 7816CCEA push ebx 

. text: 7816CCEB call [esp+118h+comp] 

. text: 7816CCF2 add esp, 8 

. text: 7816CCF5 test eax, eax 

. text: 7816CCF7 jle short loc 7816CD04 


comp—est le quatriéme argument de la fonction. Ici, le contróle est passé à l'adresse 
dans l'argument comp. Avant cela, deux arguments sont préparés pour comp(). Son 
résultat est testé aprés son exécution. 


C'est pourquoi il est dangereux d'utiliser des pointeurs sur des fonctions. Tout d'abord, 
si vous appelez qsort() avec un pointeur de fonction incorrect, qsort() peut pas- 
ser le contróle du flux à un point incorrect, le processus peut planter et ce bug sera 

difficile à trouver. 


La seconde raison est que les types de la fonction de callback doivent étre stricte- 
ment conforme, appeler la mauvaise fonction avec de mauvais arguments du mau- 
vais type peut conduire à de sérieux problémes, toutefois, le plantage du processus 
n'est pas un probléme ici —le probléme est de comment déterminer la raison du 
plantage —car le compilateur peut étre silencieux sur le probléme potentiel lors de 
la compilation. 
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MSVC + OllyDbg 


Chargeons notre exemple dans OllyDbg et mettons un point d'arrêt sur comp (). Nous 
voyons comment les valeurs sont comparées lors du premier appel de comp() : 


CPU - main thread, module 17_1 AS 
^ 


SB4424 84 MOU EAX, DWORD PTR SS: CARG. 1] isters (FPU) 

SB4C24 68 MOV ECX, DWORD PTR SS: CARG.21 60909764 
rey Ee es ET DE T -— 

EAN EUX H lalala lalala] 


Cc 
JNE SHORT BOFD1613 Erro 


E pu 

e EDH, EDS EDI BO37FEBS 

SETGE DL EIP 8BFDiB8C 17 1.88FD188C 

LEA EAX, LEDX«EDX-11 ES 8 Bt FFFFFFFF) 
TNTS : D EFFFFFFE) 

3 [5] 
Fi ds @(FFFFFFFF) 
— TEFDDaaatFFF) 

OCFFFFFFFF) 


ECx=5 
EAX=00000764 (decimal 1892.) 


OOANNDDO 
Coo 


mno 
rom 
J TI 


OATS 


oon 


Oe 
JOO 
LOO 


DUB 
c 


Fig. 1.109: OllyDbg : premier appel de comp() 


OllyDbg montre les valeurs comparées dans la fenétre sous celle du code, par com- 
modité. Nous voyons que SP pointe sur RA, oü se trouve la fonction qsort() (dans 
MSVCR100.DLL). 


500 


En tracant (F8) jusqu'à l'instruction RETN et appuyant sur F8 une fois de plus, nous 
retournons à la fonction qsort() : 


JMP SHORT 6ESF4RCF 

SHR EAX, 1 

IMUL EBX, EAX 

ADD EBX, EDI 

PUSH EBX 

CALL DWORD PTR SS: LEBP+14] 
TEST EAX, EAX 

JLE SHORT 6E3F4B53 

MOU EDX, DWORD PTR SS: [EBP+10] 
MOU EAX, EBX 

CMP EDI, EBX 

JE SHORT 6E3F4B53 

HOU ECX, EDI 2 t B(FFFFFFFF) 


rEFDDaaatFFF) 
t @(FFFFFFFF) 


Fig. 1.110: OllyDbg : le code dans qsort() juste aprés l'appel de comp() 


Ca a été un appel à la fonction de comparaison. 


Voici aussi une copie d'écran au moment du second appel àcomp( ) —maintenant les 


valeurs qui doivent étre comparées sont différentes: 


CPU - main thread, module 17 1 


5 SB4424 84 
* 8B4C24 68 


XOR EAX, EAX 


RETN 

XOR EDX, EDX 
CMP _EAX, ECX 
SETGE DL 


MOU EAX, DWORD PTR SS: CARG. 1] 
MOU ECX, DWORD PTR SS:[ARG. 2] 
MOU EAX, DWORD PTR DS:LERA1 
MOU ECX, DWORD PTR DS:[ECX] 


[n 
JNE SHORT 60FD1613 


LER EAX, [EDX+EDX-1] 
RETN 


Fig. 1.111: OllyDbg : second appel de comp () 


MSVC + tracer 


Regardons quelles sont le paires comparées. Ces 10 nombres vont étre triés: 1892, 


45, 200, -98, 4087, 5, -12345, 1087, 88, -100000. 


Nous avons l'adresse de la première instruction CMP dans comp(), c'est 0x0040100C 


et nous y avons mis un point d'arrét: 


@( FFFFFFFF) 
GC FFFFFFFF) 
@(FFFFFFFF) 
TEFODGGG(FFF) 


BtFFFFFFFF) 


tracer.exe -1:17 l.exe bpx-17 1.exe!0x0040100C 


Maintenant nous avons des informations sur les registres au point d'arrét: 


PID-4336|New process 17 1.exe 
(0) 17 1.exe!0x40100c 
EAX=0x00000764 EBX-0x0051f7c8 
ESI=0x0051f7d8 EDI=0x0051f7b4 
EIP-0x0028100c 

FLAGS-IF 

(0) 17 1.exe!0x40100c 
EAX=0x00000005 EBX-0x0051f7c8 
ESI-0x0051f7d8 EDI-0x0051f7b4 
EIP-0x0028100c 

FLAGS-PF ZF IF 

(0) 17 1.exe!0x40100c 
EAX=0x00000764 EBX-0x0051f7c8 
ESI-0x0051f7d8 EDI-0x0051f7b4 
EIP-0x0028100c 

FLAGS=CF PF ZF IF 


ECX-0x00000005 
EBP=0x0051f794 


ECX=0xfffe7960 
EBP=0x0051f794 


ECX=0x00000005 
EBP=0x0051f794 


EDX=0x00000000 
ESP=0x0051f67c 


EDX=0x00000000 
ESP=0x0051f67c 


EDX=0x00000000 
ESP=0x0051f67c 
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Filtrons sur EAX et ECX et nous obtenons: 


EAX=0x00000764 
EAX=0x00000005 
EAX=0x00000764 
EAX=0x0000002d 
EAX=0x00000058 
EAX=0x0000043f 
EAX=0xffffcfc7 
EAX=0x000000c8 
EAX-Oxffffff9e 
EAX=0x00000ff7 
EAX=0x00000ff7 
EAX-Oxffffff9e 
EAX-Oxffffff9e 
EAX-Oxffffcfc7 
EAX-0x00000005 
EAX-Oxffffff9e 
EAX-Oxffffcfc7 
EAX-Oxffffff9e 
EAX-Oxffffcfc7 
EAX=0x000000c8 
EAX=0x0000002d 
EAX=0x0000043f 
EAX=0x00000058 
EAX=0x00000764 
EAX-0x000000c8 
EAX-0x0000002d 
EAX=0x0000043f 
EAX=0x00000058 
EAX-0x000000c8 
EAX-0x0000002d 
EAX=0x0000043f 
EAX=0x000000c8 
EAX=0x0000002d 
EAX=0x0000002d 


ECX=0x00000005 
ECX=0xfffe7960 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0x00000005 
ECX=0xfffe7960 
ECX=0xffffcfc7 
ECX=0x00000005 
ECX=0xfffe7960 
ECX=0xffffcfc7 
ECX=0xfffe7960 
ECX=0x00000ff7 
ECX=0x00000ff7 
ECX=0x00000ff7 
ECX=0x00000ff7 
ECX=0x00000ff7 
ECX=0x00000764 
ECX=0x00000764 
ECX=0x00000764 
ECX=0x00000764 
ECX=0x00000058 
ECX=0x000000c8 
ECX=0x000000c8 
ECX=0x00000058 
ECX=0x000000c8 
ECX=0x00000058 


Il y a 34 paires. 


C'est pourquoi, l'algorithme de tri rapide a besoin de 34 opérations 
de comparaison pour trier ces 10 nombres. 
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MSVC + tracer (couverture du code) 


Nous pouvons aussi utiliser la capacité du tracer pour collecter tous les registres 
possible et les montrer dans IDA. 


Exécutons pas a pas toutes les instructions dans comp() : 


tracer.exe -1:17 1.exe bpf=17 1.exe!0x00401000,trace:cc 


Nous obtenons un scipt .idc pour charger dans IDA et chargeons le: 


.text: 66461666 


-text:60461606 ; int _ cdecl PtFuncCompare(const void *, const void x) 


-text:66461666 
-text:66461666 
-text:66461666 
-text:66461666 
-text:66461666 
-text:66461666 
-text:00501005 
-text:00581008 
-text : 6646166A 
- text : 66461 66C 
-text : 664601 66E 
- text : 66461616 
- text : 66461612 


.text:00401013 ; 


-text : 66461613 
- text : 66461613 
- text : 66461613 
- text : 664616015 
- text : 66461617 
- text: 66461601A 
.text:0040101E 
.text:0040101E 
-rext -RfühftmF 


PtFuncCompare 


arg 8 
arg ^ 


loc 581813: 


PtFuncCompare 


proc near 5 DATA XREF: _main+5jo 


duord ptr 4 
duord ptr 8 


mou eax, [esp*arg 8] ; [ESP+4]=0x45f7ec..0x45f810(step=4), L'?1x047 
mou ecx, [esp*arg ^] ; [ESP*8]-8xh5f7ec..8xh5f7fh(step-h), 8xh5f?fc 
mou eax, [eax] ; [EAX]=5, 0x2d, 0x58, 8xc8, 0x43f, 0x764, OxFf 
mou ecx, [ecx] ; [ECX]-5, 0x58, Gxc8, 6x764, Oxff7, Oxfffe7968 
cnp eax, ecx ; EAX=5, 6x2d, 0x58, Oxc8, 6x43f, 0x764, Oxff7, 
jnz short loc 5481813 ; 2F-false 
xor eax, eax 
retn 

; CODE XREF: PtFuncCompare+E?j 
xor edx, edx 
cnp eax, ecx ; EAX=5, 6x2d, 0x58, Oxc8, Oxh3f, 0x764, Oxff7, 
setnl dl ; SF-false,true OF=false 
lea eax, [edx+edx-1] 
retn ; EAX=1, OxffffFFff 
endp 


Fig. 1.112: tracer et IDA. N.B.: certaines valeurs sont coupées à droite 


IDA a donné un nom à la fonction (PtFuncCompare)—car IDA voit que le pointeur sur 
cette fonction est passé à qsort(). 


Nous voyons que les pointeurs a et b pointent sur différents emplacements dans le 
tableau, mais le pas entre eux est 4, puisque des valeurs 32-bit sont stockées dans 


le tableau. 


Nous voyons quelles instructions en 0x401010 et 0x401012 ne sont jamais exécutées 
(donc elles sont laissées en blanc) : en effet, comp() ne renvoie jamais 0, car il n'y 
a pas d'éléments égaux dans le tableau. 


1.33.2 GCC 


Il n'y a pas beaucoup de différence: 


Listing 1.367 : GCC 


lea 
mov 


eax, [esp+40h+var 28] 
[esp+40h+var 40], eax 
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mov [esp+40h+var_28], 764h 

mov [esp+40h+var_24], 2Dh 

mov [esp+40h+var_20], 0C8h 

mov [esp+40h+var_1C], OFFFFFF9Eh 
mov [esp+40h+var_18], OFF7h 

mov [esp+40h+var_14], 5 

mov [esp+40h+var_10], OFFFFCFC7h 
mov [esp+40h+var_C], 43Fh 

mov [esp+40h+var_8], 58h 

mov [esp+40h+var_4], OFFFE7960h 
mov [esp+40h+var_34], offset comp 
mov [esp+40h+var 38], 4 

mov [esp+40h+var_3C], 0Ah 

call _qsort 


Fonction comp() : 


public comp 


comp proc near 
arg 0 = dword ptr 8 
arg 4 = dword ptr OCh 
push ebp 
mov ebp, esp 
mov eax, [ebp+arg_4] 
mov ecx, [ebp+arg 0] 
mov edx, [eax] 
xor eax, eax 
cmp [ecx], edx 
jnz short loc 8048458 
pop ebp 
retn 
loc 8048458: 
setnl al 
movzx eax, al 
lea eax, [eax+eax-1] 
pop ebp 
retn 
comp endp 


L'implémentation de qsort() se trouve dans libc.so.6 et c'est en fait juste un 
wrapper!* pour qsort r(). 


À son tour, elle appelle quicksort(), oü notre fonction défini est appelée via le 
pointeur passé: 


Listing 1.368 : (fihier libc.so.6, glibc version— 2.10.1) 


.text:0002DDF6 mov edx, [ebp+arg 10] 
.text:0002DDF9 mov [esp*4], esi 


16645 concept similaire à une fonction thunk 
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.text:0002DDFD mov [esp], edi 
.text:0002DE00 mov [esp+8], edx 


.text:0002DE04 call [ebp+arg_C] 


GCC + GDB (avec code source) 


Évidemment, nous avons le code source C de notre exemple (1.33 on page 496), 
donc nous pouvons mettre un point d'arrét (b) sur le numéro de ligne (11—la ligne 
oü la premiére comparaison se produit. Nous devons aussi compiler l'exemple avec 
les informations de débogage incluses (-g), donc la table avec les adresses et les 
numéros de ligne correspondants est présente. 


Nous pouvons aussi afficher les valeurs en utilisant les noms de variable (p) : les 
informations de débogage nous disent aussi quel registre et/ou élément de la pile 
locale contient quelle variable. 


Nous pouvons aussi voir la pile (bt) et y trouver qu'il y a une fonction intermédiaire 
msort with tmp() utilisée dans la Glibc. 


Listing 1.369 : session GDB 


dennis@ubuntuvm:~/polygon$ gcc 17 1.c -g 
dennis@ubuntuvm:~/polygon$ gdb ./a.out 

GNU gdb (GDB) 7.6.1-ubuntu 

Copyright (C) 2013 Free Software Foundation, Inc. 


Reading symbols from /home/dennis/polygon/a.out...done. 
(gdb) b 17 1.c:11 

Breakpoint 1 at 0x804845f: file 17 1.c, line 11. 

(gdb) run 

Starting program: /home/dennis/polygon/./a.out 


Breakpoint 1, comp (_a=0xbffff0f8, b= bgentry-OxbffffOfc) at 17 1.c:11 
11 if (*a==*b) 


(gdb) c 
Continuing. 


Breakpoint 1, comp (_a=0xbffff104, b= b@entry-0xbffff108) at 17 1.c:11 
11 if (*a==*b) 


(gdb) bt 

#0 comp (_a=0xbffff0f8, b= bgentry-OxbffffOfc) at 17 1.c:11 

#1 0xb7e42872 in msort with tmp (p=pGentry=0xbffff07c, b=b@entry=0 7 
V xbffffOf8, n=n@entry=2) 
at msort.c:65 
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#2  0xb7e4273e in msort_with_tmp (n=2, b=0xbffff0f8, p=0xbffff07c) at msort” 
Y .c:45 

#3 msort with tmp (p=pGentry=0xbffff07c, b-bgentry-OxbffffOf8, n=nfentry 
Y =5) at msort.c:53 

#4  0xb7e4273e in msort with tmp (n=5, b=0xbffff0f8, p=0xbffff07c) at msort” 
V .c:45 

#5 msort with tmp (p=pGentry=0xbffff07c, b-bgentry-OxbffffOf8, n=n@entry x7 
V =10) at msort.c:53 

#6  0xb7e42cef in msort with tmp (n=10, b=0xbffff0f8, p=0xbffff07c) at 2 
G msort.c:45 

#7 GI qsort r (b-bgentry-OxbffffOf8, n=n@entry=10, s=s@entry=4, cmp=2 
& cmp@ent ry=0x804844d «comp», 
arg=arg@entry=0x0) at msort.c:297 

#8 Oxb7e42dcf in GI qsort (b=0xbffff0f8, n=10, s-4, cmp=0x804844d «comp; 
S >) at msort.c:307 

#9 0x0804850d in main (argc=1, argv=0xbffff1c4) at 17 1.c:26 

(gdb) 


GCC + GDB (pas de code source) 


Mais souvent, il n'y a pas de code source du tout, donc nous pouvons désassembler 
la fonction comp() (disas), trouver la toute premiére instruction CMP et placer un 
point d'arrét (b) à cette adresse. 


À chaque point d'arrét, nous allons afficher le contenu de tous les registres 
(info registers). Le contenu de la pile est aussi disponible (bt), 


mais partiellement: il n'y a pas l'information du numéro de ligne pour comp). 


Listing 1.370 : session GDB 


dennis@ubuntuvm:~/polygon$ gcc 17 1.c 
dennis@ubuntuvm:~/polygon$ gdb ./a.out 

GNU gdb (GDB) 7.6.1-ubuntu 

Copyright (C) 2013 Free Software Foundation, Inc. 


Reading symbols from /home/dennis/polygon/a.out...(no debugging symbols 2 
V found)...done. 

(gdb) set disassembly-flavor intel 

(gdb) disas comp 

Dump of assembler code for function comp: 


0x0804844d «40»: push ebp 

0x0804844e <+1>: mov ebp,esp 

0x08048450 «43»: sub esp, 0x10 

0x08048453 «46»: mov eax,DWORD PTR [ebp+0x8] 
0x08048456 «49»: mov DWORD PTR [ebp-0x8],eax 
0x08048459 «412»: mov eax,DWORD PTR [ebp+0xc] 
0x0804845c <+15>: mov DWORD PTR [ebp-0x4],eax 
0x0804845f <+18>: mov eax,DWORD PTR [ebp-0x8] 
0x08048462 <+21>: mov edx, DWORD PTR [eax] 
0x08048464 <+23>: mov eax,DWORD PTR [ebp-0x4] 
0x08048467 «426»: mov eax,DWORD PTR [eax] 


0x08048469 «4-282»: cmp edx,eax 
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0x0804846b <+30>: jne 0x8048474 <comp+39> 
0x0804846d <+32>: mov eax,0x0 

0x08048472 «4375»: jmp 0x804848e <comp+65> 
0x08048474 <+39>: mov eax,DWORD PTR [ebp-0x8] 
0x08048477 <+42>: mov edx, DWORD PTR [eax] 
0x08048479 <+44>: mov eax,DWORD PTR [ebp-0x4] 
0x0804847c <+47>: mov eax, DWORD PTR [eax] 
0x0804847e <+49>: cmp edx,eax 

0x08048480 «451»: jge 0x8048489 <comp+60> 
0x08048482 <+53>: mov eax,0xffffffff 
0x08048487 «4-58»: jmp 0x804848e <comp+65> 
0x08048489 <+60>: mov eax,0x1 

0x0804848e «465»: leave 

0x0804848f «466»: ret 


End of assembler dump. 

(gdb) b *0x08048469 

Breakpoint 1 at 0x8048469 

(gdb) run 

Starting program: /home/dennis/polygon/./a.out 


Breakpoint 1, 0x08048469 in comp () 
(gdb) info registers 


eax 0x2d 45 

ecx OxbffffOf8 -1073745672 
edx 0x764 1892 

ebx Oxb7 fc0000 - 1208221696 
esp Oxbfffeeb8 Oxbfffeeb8 
ebp Oxbfffeec8 Oxbfffeec8 
esi OxbffffOfc -1073745668 
edi Oxbffff010 -1073745904 
eip 0x8048469 0x8048469 <comp+28> 
eflags 0x286 [ PF SF IF ] 

cs 0x73 115 

ss Ox7b 123 

ds Ox7b 123 

es Ox7b 123 

fs 0x0 0 

gs 0x33 51 

(gdb) c 

Continuing. 


Breakpoint 1, 0x08048469 in comp () 
(gdb) info registers 


eax Oxff7 4087 

ecx Oxbffff104 -1073745660 

edx Oxffffff9e -98 

ebx Oxb7 fc0000 - 1208221696 

esp Oxbfffee58 Oxbfffee58 

ebp Oxbfffee68 Oxbfffee68 

esi Oxbffff108 -1073745656 

edi Oxbffff010 -1073745904 

eip 0x8048469 0x8048469 <comp+28> 
eflags 0x282 [ SF IF ] 
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CS 0x73 115 
ss 0x7b 123 
ds 0x7b 123 
es 0x7b 123 
fs 0x0 0 
gs 0x33 51 
(gdb) c 

Continuing. 


Breakpoint 1, 0x08048469 in comp () 
(gdb) info registers 


eax Oxffffff9e -98 

ecx Oxbffff100 -1073745664 
edx Oxc8 200 

ebx Oxb7 fc0000 - 1208221696 
esp Oxbfffeeb8 Oxbfffeeb8 
ebp Oxbfffeec8 Oxbfffeec8 
esi Oxbffff104 -1073745660 
edi Oxbffff010 -1073745904 
eip 0x8048469 0x8048469 <comp+28> 
eflags 0x286 [ PF SF IF ] 

cs 0x73 115 

ss Ox7b 123 

ds Ox7b 123 

es Ox7b 123 

fs 0x0 0 

gs 0x33 51 

(gdb) bt 

#0 0x08048469 in comp () 


#8 


#9 


0xb7e42872 in msort with tmp (p=pGentry=0xbffff07c, b=b@entry=07 

V xbffffOf8, n=n@entry=2) 

at msort.c:65 

0xb7e4273e in msort with tmp (n=2, b=0xbffff0f8, p=0xbffff07c) at msort” 
Y .c:45 

msort with tmp (p=pGentry=0xbffff07c, b=b@entry=0xbffff0f8, nzngentry 
S -5) at msort.c:53 

0xb7e4273e in msort with tmp (n=5, b=0xbffff0f8, p=0xbffff07c) at msort” 
V .c:45 

msort with tmp (p=pGentry=0xbffff07c, bzbgentryzOxbffffOf8, n=n@entry, 
S -10) at msort.c:53 

Oxb7e42cef in msort with tmp (n=10, b=0xbffff0f8, p=0xbffff07c) at 7 

G msort.c:45 

. GI qsort r (b-bgentry-OxbffffOf8, n=n@entry=10, s=s@entry=4, cmp=2 

& cmp@ent ry=0x804844d «comp», 

arg=arg@entry=0x0) at msort.c:297 

Oxb7e42dcf in GI qsort (b=0xbffff0f8, n=10, s-4, cmp=0x804844d «comp 
>) at msort.c:307 

0x0804850d in main () 
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1.33.3 Danger des pointeurs sur des fonctions 


Comme nous pouvons le voir, la fonction qsort () attend un pointeur sur une fonction 
qui prend deux arguments de type void* et renvoie un entier: Si vous avez plusieurs 
fonctions de comparaison dans votre code (une qui compare les chaînes, une autre— 
les entiers, etc.), il est trés facile de les mélanger les unes avec les autres. Vous 
pouvez essayer de trier un tableau de chaine en utilisant une fonction qui compare 
les entiers, et le compilateur ne vous avertira pas de ce bogue. 


1.34 Valeurs 64-bit dans un environnement 32-bit 


Dans un environnement 32-bit, les GPR sont 32-bit, donc les valeurs 64-bit sont 
stockées et passées comme une paire de registres 32-bit!97. 


1.34.1 Renvoyer une valeur 64-bit 


#include «stdint.h» 


uint64 t f () 
1 


}; 


return 0x1234567890ABCDEF ; 


x86 


Dans un environnement 32-bit, les valeurs 64-bit sont renvoyées des fonctions dans 
la paire de registres EDX :EAX. 


Listing 1.371 : MSVC 2010 avec optimisation 


f PROC 
mov eax, -1867788817 ; 90abcdefH 
mov edx, 305419896 ; 12345678H 
ret 0 

f ENDP 

ARM 


Une valeur 64-bit est renvoyée dans la paire de registres RO-R1 (R1 est pour la partie 
haute et RO pour la partie basse) : 


Listing 1.372 : avec optimisation Keil 6/2013 (Mode ARM) 


|| f] |] PROC 
LDR r0,|L0.12| 
LDR r1,|L0.16| 
BX lr 


167A propos, les valeurs 32-bit sont passées en tant que paire dans les environnements 16-bit de la méme 
maniére: 3.34.4 on page 843 
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ENDP 
[L0.12| 

DCD 0x90abcdef 
[L0.16| 

DCD 0x12345678 
MIPS 


Une valeur 64-bit est renvoyée dans la paire de registres VO-V1 ($2-$3) (VO ($2) est 
pour la partie haute et V1 ($3) pour la partie basse) : 


Listing 1.373 : GCC 4.4.5 avec optimisation (listing assembleur) 


li $3,-1867841536 + Oxffffffff90ab0000 
li $2,305397760 # 0x12340000 

ori $3,$3,0xcdef 

j $31 

ori $2,$2,0x5678 


Listing 1.374 : GCC 4.4.5 avec optimisation (IDA) 


lui $v1, Ox90AB 

lui $v0, 0x1234 

li $v1, Ox90ABCDEF 
jr $ra 

li $v0, 0x12345678 


1.34.2 Passage d'arguments, addition, soustraction 


#include <stdint.h> 


uint64 t f add (uint64 t a, uint64 t b) 
1 


return atb; 


void f add test () 


1 
#ifdef | GNUC — 

printf ("%lld\n", f add(12345678901234, 23456789012345)); 
#else 

printf ("%I64d\n", f add(12345678901234, 23456789012345) ); 
#endif 
}; 


uint64 t f sub (uint64 t a, uint64 t b) 
{ 


}; 


return a-b; 
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x86 
Listing 1.375 : MSVC 2012 /Ob1 avec optimisation 
_a$ = 8 ; size = 8 
_b$ = 16 ; size = 8 
_f_add PROC 
mov eax, DWORD PTR _a$[esp-4] 
add eax, DWORD PTR b$[esp-4] 
mov edx, DWORD PTR a$[esp] 
adc edx, DWORD PTR _b$[esp] 
ret 0 
f add ENDP 
f add test PROC 
push 5461 ; 00001555H 
push 1972608889 ; 75939f79H 
push 2874 ; 00000b3aH 
push 1942892530 ; 73ce2ff2H 
call f add 
push edx 
push eax 
push OFFSET $SG1436 ; '%164d', 0aH, 00H 
call _printf 
add esp, 28 
ret 0 
f add test ENDP 
_f sub PROC 
mov eax, DWORD PTR  a$[esp-4] 
sub eax, DWORD PTR b$[esp-4] 
mov edx, DWORD PTR a$[esp] 
sbb edx, DWORD PTR _b$[esp] 
ret 0 
f sub ENDP 


Nous voyons dans la fonction f add test() que chaque valeur 64-bit est passée en 
utilisant deux valeurs 32-bit, partie haute d'abord, puis partie basse. 


L'addition et la soustraction se déroulent aussi par paire. 


Pour l'addition, la partie basse 32-bit est d'abord additionnée. Si il y a eu une retenue 
pendant l'addition, le flag CF est mis. 


L'instruction suivante ADC additionne les parties hautes, et ajoute aussi 1 si CF — 1. 


La soustraction est aussi effectuée par paire. Le premier SUB peut aussi mettre le 
flag CF, qui doit étre testé lors de l'instruction SBB suivante: Si le flag de retenue est 
mis, alors 1 est soustrait du résultat. 


Il est facile de voir comment le résultat de la fonction f add() est passé à printf(). 


Listing 1.376 : GCC 4.8.1 -O1 -fno-inline 


f add: 
mov eax, DWORD PTR [esp+12] 
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mov 
add 
adc 
ret 


f add test: 
sub 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
call 
add 
ret 


_f sub: 
mov 
mov 
sub 
sbb 
ret 


edx, DWORD PTR [esp+16] 
eax, DWORD PTR [esp+4] 
edx, DWORD PTR [esp+8] 


esp, 28 

DWORD PTR [esp+8], 1972608889 ; 75939f79H 
DWORD PTR [esp+12], 5461 ; 00001555H 
DWORD PTR [esp], 1942892530 ; 73ce2ff2H 
DWORD PTR [esp+4], 2874 ; 00000b3aH 


f add 

DWORD PTR [esp+4], eax 

DWORD PTR [esp+8], edx 

DWORD PTR [esp], OFFSET FLAT:LCO ; "%lld\n" 
| printf 

esp, 28 


eax, DWORD PTR [esp+4] 
edx, DWORD PTR [esp+8] 
eax, DWORD PTR [esp+12] 
edx, DWORD PTR [esp+16] 


Le code de GCC est le méme. 


ARM 
Listing 1.377 : avec optimisation Keil 6/2013 (Mode ARM) 
f_add PROC 
ADDS r0,r0,r2 
ADC rl,r1,r3 
BX lr 
ENDP 
f sub PROC 
SUBS ro, r0, r2 
SBC rl,r1,r3 
BX lr 
ENDP 
f_add_test PROC 
PUSH {r4, lr} 
LDR r2,|L0.68| ; 0x75939f79 
LDR r3,|L0.72| ; 0x00001555 
LDR r0,|L0.76| ; 0x73ce2ff2 
LDR r1,|L0.80| ; 0x00000b3a 
BL f add 
POP {r4,lr} 


MOV r2,r0 


513 


MOV r3,r1 

ADR r0,|L0.84| ; "%I64d\n" 

B _ 2printf 

ENDP 
|LO.68 | 

DCD 0x75939f79 
[L0.72| 

DCD 0x00001555 
[L0.76| 

DCD 0x73ce2ff2 
[L0.80| 

DCD 0x00000b3a 
[L0.84| 

DCB "sI64din",0 


La premiére valeur 64-bit est passée par la paire de registres RO et R1, la seconde 
dans la paire de registres R2 et R3. ARM a aussi l'instruction ADC (qui compte le flag de 
retenue) et SBC («soustraction avec retenue »). Chose importante: lorsque les parties 
basses sont ajoutées/soustraites, les instructions ADDS et SUBS avec le suffixe -S sont 
utilisées. Le suffixe -S signifie «mettre les flags », et les flags (en particulier le flag de 
retenue) est ce dont les instructions suivantes ADC/SBC ont besoin. Autrement, les 
instructions sans le suffixe -S feraient le travail (ADD et SUB). 


MIPS 


Listing 1.378 : GCC 4.4.5 avec optimisation (IDA) 


f add: 
; $a0 - partie haute de a 
; $al - partie basse de a 
; $a2 - partie haute de b 
; $a3 - partie basse de b 
addu $v1l, $a3, $al ; ajouter les parties basses 
addu $a0, $a2, $a0 ; ajouter les parties hautes 
; est-ce qu'une retenue a été générée lors de l'addition des parties basses? 
; Si oui, mettre $v0 à 1 
sltu $v0, $vl, $a3 
jr $ra 
; ajouter 1 à la partie haute du résultat si la retenue doit étre générée: 
addu $v0, $a0 ; slot de délai de branchement 
; $vO - partie haute du résultat 
; $v1 - partie basse du résultat 


f sub: 

; $a0 - partie haute de a 

; $al - partie basse de a 

; $a2 - partie haute de b 

; $a3 - partie basse de b 
subu $v1, $al, $a3 ; soustraire les parties basses 
subu $v0, $a0, $a2 ; soustraire les parties hautes 

; est-ce qu'une retenue a été générée lors de la soustraction des parties 

basses? 
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; Si oui, mettre $a0 à 1 
sltu $al, $v1 


jr $ra 
; Soustraire 1 à la partie haute du résultat si la retenue doit étre générée: 
subu $v0, $al ; slot de délai de branchement 


; $v0 - partie haute du résultat 
; $v1 - partie basse du résultat 


f add test: 
var 10 = -0x10 
var_4 = -4 
lui $gp, (__gnu_local_gp >> 16) 
addiu $sp, -0x20 
la $gp, ( gnu local gp € OxFFFF) 
SW $ra, Ox20+var 4($sp) 
sw $gp, Ox20+var 10($sp) 
lui $al, 0x73CE 
lui $a3, 0x7593 
li $a0, 0xB3A 
li $a3, 0x75939F79 
li $a2, 0x1555 
jal f_add 
li $al, 0x73CE2FF2 
lw $gp, Ox20+var 10($sp) 
lui $a0, ($LCO >> 16) # "Slld\n" 
lw $t9, (printf € OxFFFF) ($gp) 
lw $ra, Ox20+var 4($sp) 
la $a0, ($LCO & OXFFFF) "95 L Ld n" 
move $a3, $v1 
move $a2, $v0 
jr $t9 
addiu $sp, 0x20 
$LCO: „ascii "slldin"<0> 


MIPS n'a pas de registre de flags, donc il n'y a pas cette information aprés l'exécution 
des opérations arithmétiques. Donc il n'y a pas d'instructions comme ADC et SBB 
du x86. Pour savoir si le flag de retenue serait mis, une comparaison est faite (en 
utilisant l'instruction SLTU), qui met le registre de destination à 1 ou 0. Ce 1 ou ce 0 
est ensuite ajouté ou soustrait au/du résultat final. 


1.34.3 Multiplication, division 


#include <stdint.h> 


uint64 t f mul (uint64 t a, uint64 t b) 
1 


return a*b; 
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uint64 t f div (uint64 t a, uint64 t b) 


1 
return a/b; 
}; 
uint64 t f rem (uint64 t a, uint64 t b) 
1 
return a % b; 
}; 
x86 


Listing 1.379 : MSVC 2013 /Ob1 avec optimisation 


_a$ = 8 ; signe = 8 
b$ = 16 ; signe = 8 


f mul PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _b$[ebp+4] 
push eax 
mov ecx, DWORD PTR _b$[ebp] 
push ecx 
mov edx, DWORD PTR _a$[ebp+4] 
push edx 
mov eax, DWORD PTR a$[ebp] 
push eax 
call . allmul ; multiplication long long 
pop ebp 
ret 0 

f mul ENDP 


_a$ = 8 ; signe = 8 
b$ = 16 ; signe = 8 


_f div PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _b$[ebp+4] 
push eax 
mov ecx, DWORD PTR _b$[ebp] 
push ecx 
mov edx, DWORD PTR _a$[ebp+4] 
push edx 
mov eax, DWORD PTR a$[ebp] 
push eax 
call . aulldiv ; division long long non signée 
pop ebp 
ret 0 

f div ENDP 


_a$ = 8 ; signe = 8 
_b$ = 16 ; signe = 8 
_f rem PROC 
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_f rem 


push 
mov 
mov 
push 
mov 
push 
mov 
push 
mov 
push 
call 
pop 
ret 
ENDP 


ebp 

ebp, esp 

eax, DWORD PTR _b$[ebp+4] 
eax 

ecx, DWORD PTR _b$[ebp] 
ecx 

edx, DWORD PTR _a$[ebp+4] 
edx 

eax, DWORD PTR a$[ebp] 
eax 

. aullrem ; reste long long non signé 
ebp 

0 


La multiplication et la division sont des opérations plus complexes, donc en général 
le compilateur embarque des appels à des fonctions de bibliothéque les effectuant. 


Ces fonctions sont décrites ici: .5 on page 1354. 


Listing 1.380 : GCC 4.8.1 -fno-inline avec optimisation 


f mul: 


_f div: 


_f rem: 


push 
mov 
mov 
mov 
mov 
imul 
imul 
mul 
add 
add 
pop 
ret 


sub 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
call 
add 
ret 


sub 
mov 
mov 


ebx 

edx, DWORD PTR [esp+8] 
eax, DWORD PTR [esp+16] 
ebx, DWORD PTR [esp+12] 
ecx, DWORD PTR [esp+20] 
ebx, eax 

ecx, edx 

edx 

ecx, ebx 

edx, ecx 

ebx 


esp, 28 

eax, DWORD PTR [esp+40] 
edx, DWORD PTR [esp+44] 
DWORD PTR [esp+8], eax 
eax, DWORD PTR [esp+32] 
DWORD PTR [esp+12], edx 
edx, DWORD PTR [esp+36] 
DWORD PTR [esp], eax 
DWORD PTR [esp+4], edx 
___ udivdi3 ; division non signé 
esp, 28 


esp, 28 
eax, DWORD PTR [esp+40] 
edx, DWORD PTR [esp+44] 
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mov DWORD PTR [esp+8], eax 

mov eax, DWORD PTR [esp+32] 

mov DWORD PTR [esp+12], edx 

mov edx, DWORD PTR [esp+36] 

mov DWORD PTR [esp], eax 

mov DWORD PTR [esp+4], edx 

call . umoddi3 ; modulo non signé 
add esp, 28 

ret 


GCC fait ce que l'on attend, mais le code multiplication est mis en ligne (inlined) 
directement dans la fonction, pensant que ca peut étre plus efficace. GCC a des 
noms de fonctions de bibliothéque différents: .4 on page 1354. 

ARM 


Keil pour mode Thumb insére des appels à des sous-routines de bibliothéque: 


Listing 1.381 : avec optimisation Keil 6/2013 (Mode Thumb) 


| | f. mut|| PROC 
PUSH 


{r4, lr} 
BL . aeabi lmul 
POP {r4,pc} 
ENDP 
|| f. div|| PROC 
PUSH {r4, lr} 
BL . aeabi uldivmod 
POP {r4,pc} 
ENDP 
||f_rem|| PROC 
PU {r4, lr} 
BL . aeabi uldivmod 
MOVS ro , r2 
MOVS r1,r3 
POP {r4,pc} 


Keil pour mode ARM, d'un autre cóté, est capable de produire le code de la multipli- 
cation 64-bit: 


Listing 1.382 : avec optimisation Keil 6/2013 (Mode ARM) 


| |f_ mul|| PROC 
PUSH {r4,lr} 
UMULL r12,r4,r0,r2 
MLA r1,r2,r1,r4 
MLA rl,r0,r3,r1 
MOV ro, r12 
POP {r4,pc} 


ENDP 
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|| f div|| PROC 
PUSH {r4, lr} 
BL . aeabi uldivmod 
POP {r4,pc} 
ENDP 
|| f. rem|| PROC 
PU {r4, lr} 
BL . aeabi uldivmod 
MOV ro, r2 
MOV rl,r3 
POP {r4,pc} 


MIPS 


GCC avec optimisation pour MIPS peut générer du code pour la multiplication 64-bit, 
mais doit appeler une routine de bibliothèque pour la division 64-bit: 


Listing 1.383 : GCC 4.4.5 avec optimisation (IDA) 


f mul: 
mult $a2, fal 
mflo $v0 
or gat, $zero ; NOP 
or gat, $zero ; NOP 
mult $a0, $a3 
mflo $a0 
addu $vO, $a0 
or gat, $zero ; NOP 
multu $a3, $al 
mfhi $a2 
mflo $v1 
jr $ra 
addu $v0, $a2 
f div: 
var 10 - -0x10 
var 4 = -4 
lui $gp, (__gnu_local_gp >> 16) 
addiu $sp, -0x20 
la $gp, (__gnu local gp € OxFFFF) 
SW $ra, Ox20+var 4($sp) 
sw $gp, Ox20+var 10($sp) 
lw $t9, ( udivdi3 € OxFFFF)($9p) 
or $at, $zero 
jalr $t9 
or $at, $zero 
lw $ra, Ox20+var_4($sp) 


or $at, $zero 
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jr $ra 
addiu  $sp, 0x20 


f_rem: 
var_10 = -0x10 
var 4 = -4 
lui $gp, (__gnu_local_gp >> 16) 
addiu $sp, -0x20 
la $gp, (__gnu local gp € OxFFFF) 
SW $ra, Ox20+var 4($sp) 
SW $gp, 0x20+var_10($sp) 
lw $t9, ( umoddi3 € OxFFFF)($9p) 
or $at, $zero 
jalr $t9 
or $at, $zero 
lw $ra, Ox20+var 4($sp) 
or $at, $zero 
jr $ra 


addiu $sp, 0x20 


Il y a beaucoup de NOPs, sans doute des slots de délai de remplissage aprés l'ins- 
truction de multiplication (c'est plus lent que les autres instructions aprés tout). 


1.34.4 Décalage à droite 


#include <stdint.h> 


uint64 t f (uint64 t a) 


1 

return a>>7; 
$; 
x86 

Listing 1.384 : MSVC 2012 /Ob1 avec optimisation 

_a$ = 8 ; size = 8 
E PROC 

mov eax, DWORD PTR  a$[esp-4] 

mov edx, DWORD PTR a$[esp] 

shrd eax, edx, 7 

shr edx, 7 

ret 0 
f ENDP 

Listing 1.385 : GCC 4.8.1 -fno-inline avec optimisation 
f: 


mov edx, DWORD PTR [esp+8] 
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mov 
shrd 
shr 
ret 


eax, DWORD PTR [esp+4] 
eax, edx, 7 
edx, 7 


Le décalage se produit en deux passes: tout d'abord la partie basse est décalée, puis 
la partie haute. Mais la partie basse est décalée avec l'aide de l'instruction SHRD, elle 
décale la valeur de EAX de 7 bits, mais tire les nouveaux bits de EDX, i.e., de la partie 
haute. En d'autres mots, la valeur 64-bit dans la paire de registres EDX:EAX, dans 
son entier, est décalée de 7 bits et les 32 bits bas du résultat sont placés dans EAX. 
La partie haute est décalée en utilisant l'instruction plus populaire SHR : en effet, les 
bits libérés dans la partie haute doivent étre remplis avec des zéros. 


ARM 


ARM n'a pas une instruction telle que SHRD en x86, donc le compilateur Keil fait cela 
en utilisant des simples décalages et des opérations OR : 


Listing 1.386 : avec optimisation Keil 6/2013 (Mode ARM) 


|| f] | PROC 

LSR r0,r0,#7 

ORR r0,r0,r1,LSL #25 

LSR rl,r1,#7 

BX lr 

ENDP 

Listing 1.387 : avec optimisation Keil 6/2013 (Mode Thumb) 

|| f] | PROC 

LSLS r2,r1,#25 

LSRS r0,r0,#7 

ORRS r0,r0,r2 

LSRS rl,r1,#7 

BX lr 

ENDP 
MIPS 


GCC pour MIPS suit le méme algorithme que Keil fait pour le mode Thumb: 


Listing 1.388 : GCC 4.4.5 avec optimisation (IDA) 


sll 
srl 
or 
jr 
srl 


$v0, $a0, 25 
$v1, fal, 7 
$v1, $v0, $v1 
$ra 


$v0, $a0, 7 
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1.34.5 Convertir une valeur 32-bit en 64-bit 


#include <stdint.h> 


int64 t f (int32 t a) 


{ 
return a; 
}; 
x86 
Listing 1.389 : MSVC 2012 avec optimisation 
_a$ = 8 
_f PROC 
mov eax, DWORD PTR _a$[esp-4] 
cdq 
ret 0 
f ENDP 


Ici, nous nous heurtons à la nécessité d'étendre une valeur 32-bit signée en une 
64-bit signée. Les valeurs non signées sont converties directement: tous les bits de 
la partie haute doivent étre mis à 0. Mais ce n'est pas approprié pour les types de 
donnée signée: le signe doit étre copié dans la partie haute du nombre résultant. 


L'instruction CDQ fait cela ici, elle prend sa valeur d'entrée dans EAX, étend le signe 
sur 64-bit et laisse le résultat dans la paire de registres EDX :EAX. En d'autres mots, 
CDQ prend le signe du nombre dans EAX (en prenant le bit le plus significatif dans 
EAX), et suivant sa valeur, met tous les 32 bits de EDX à O ou 1. Cette opération est 
quelque peu similaire à l'instruction MOVSX. 


ARM 
Listing 1.390 : avec optimisation Keil 6/2013 (Mode ARM) 
||| | PROC 
ASR r1,r0,#31 
BX lr 
ENDP 


Keil pour ARM est différent: il décale simplement arithmétiquement de 31 bits vers 
la droite la valeur en entrée. Comme nous le savons, le bit de signe est le MSB, et 
le décalage arithmétique copie le bit de signe dans les bits «apparus ». Donc aprés 
«ASR r1,r0,#31», R1 contient OxFFFFFFFF si la valeur d'entrée était négative et O 
sinon. R1 contient la partie haute de la valeur 64-bit résultante. En d'autres mots, ce 
code copie juste le MSB (bit de signe) de la valeur d'entrée dans RO dans tous les 
bits de la partie haute 32-bit de la valeur 64-bit résultante. 


MIPS 


GCC pour MIPS fait la méme chose que Keil a fait pour le mode ARM: 
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Listing 1.391 : GCC 4.4.5 avec optimisation (IDA) 


f: 
sra $v0, $a0, 31 
jr $ra 
move $v1, $a0 


1.35 Cas d'une structure LARGE INTEGER 


Imaginez ceci: fin des années 1990, vous étes Microsoft, et vous développez un 
nouvel OS sérieux (Windows NT), qui doit concurrencer les systémes UNIX. Les plate- 
formes cibles sont à la fois les CPUs 32-bit et 64-bit. Et vous avez besoin d'un type 
de donnée entier 64-bit pour toutes sortes de besoins, à commencer par la structure 
FILETIME+°® 


Le probleme: tous les compilateurs C/C++ cibles ne supportent pas encore les en- 
tiers 64-bit (ceci se passe a la fin des années 1990). Sans aucun doute, ceci sera 
changé dans le futur (proche), mais pas maintenant. Que feriez-vous? 


En lisant ceci, essayez d’arréter (et/ou de fermer ce livre) et réfléchissez a comment 
vous résoudriez ce probléme. 


168https://docs.microsoft.com/en-us/windows/desktop/api/minwinbase/ 
ns-minwinbase-filetime 
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Voici ce que fit Microsoft, quelque chose comme ceci!*? : 


union ULARGE INTEGER 
1 
struct backward compatibility 
1 
DWORD LowPart; 
DWORD HighPart; 


}; 

#ifdef NEW FANCY COMPILER SUPPORTING 64 BIT 
ULONGLONG QuadPart; 

#endif 

}; 


Ceci est un fragment de 8 octets, qui peut être accédé par l'entier 64-bit QuadPart 
(si il est compilé avec un compilateur récent) ou en utilisant deux entiers 32-bit (si 
compilé avec un compilateur plus ancien). 


Le champ QuadPart est simplement absent lorsque c'est compilé avec un vieux com- 
pilateur. 


L'ordre est crucial: le premier champ (LowPart) correspond au 4 octets de la valeur 
64-bit, le second (HighPart) au 4 octets hauts. 


Microsoft a aussi ajouté des fonctions utilitaires pour les différentes opérations arith- 
métiques, de la même façon que je l'ai déjà décrit: 1.34 on page 509. 


Et ceci provient du code source de Windows 2000 qui avait été divulgué: 


Listing 1.392 : i386 arch 


¡++ 


LARGE_INTEGER 
RtlLargeIntegerAdd ( 

; IN LARGE INTEGER Addend1, 
IN LARGE INTEGER Addend2 
5) 


Routine Description: 


; This function adds a signed large integer to a signed large integer and 
; returns the signed large integer result. 


; Arguments: 


; (TOS+4) = Addendl - first addend value 
; (TOS+12) = Addend2 - second addend value 


; Return Value: 
; The large integer result is stored in (edx:eax) 


, 


169Ce n'est pas un copier/coller du code source, j'ai écrit ceci 
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cPublicProc RtlLargeIntegerAdd ,4 
cPublicFpo 4,0 


mov eax, [esp]+4 ; (eax)=add1. low 
add eax, [esp]+12 ; (eax)=sum. low 
mov edx, [esp]+8 ; (edx)=add1.hi 
adc edx, [esp]+16 ; (edx)=sum.hi 
stdRET _RtlLargeIntegerAdd 


StdENDP RtlLargeIntegerAdd 


Listing 1.393 : MIPS arch 


LEAF ENTRY (RtlLargeIntegerAdd) 


lw t0,4 * 4(sp) // get low part of addend2 value 
lw t1,4 * 5(sp) // get high part of addend2 value 
addu t0,t0,a2 // add low parts of large integer 
addu t1,t1,a3 // add high parts of large integer 
sltu t2,t0,a2 // generate carry from low part 
addu t1,t1,t2 // add carry to high part 

SW t0,0(a0) // store low part of result 

SW t1,4(a0) // store high part of result 

move v0,a0 // set function return register 

j ra // return 


.end RtlLargeIntegerAdd 


Maintenant deux architectures 64-bit: 


Listing 1.394 : Itanium arch 


LEAF_ENTRY(RtlLargeIntegerAdd) 

add vO = a0, al // add both quadword 7 
y arguments 

LEAF RETURN 


LEAF EXIT(RtlLargeIntegerAdd) 


Listing 1.395 : DEC Alpha arch 


LEAF ENTRY (RtlLargeIntegerAdd) 


addq a0, al, vO // add both quadword arguments 
ret zero, (ra) // return 


.end RtlLargeIntegerAdd 


Pas besoin d'utiliser des instructions 32-bit sur Itanium et DEC Alpha—qui soient déjà 
prétes pour le 64-bit. 


Et voici ce que l'on peut trouver dans Windows Research Kernel: 
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DECLSPEC_DEPRECATED_DDK // Use native  int64 math 
_ inline 
LARGE_INTEGER 
NTAPI 
RtlLargeIntegerAdd ( 
LARGE INTEGER Addendl, 
LARGE INTEGER Addend2 
) 


1 
LARGE INTEGER Sum; 
Sum.QuadPart = Addend1.QuadPart + Addend2.QuadPart; 
return Sum; 

} 


Toutes ces fonctions pourront être supprimées (dans le futur), mais maintenant elles 
opèrent sur le champ QuadPart. Si ce morceau de code doit être compilé en utilisant 
un compilateur 32-bit moderne (qui supporte les entiers 64-bit), il générera deux 
additions 32-bit sous le capot. À partir de ce moment, les champs LowPart/HighPart 
pourront être supprimés de l'union/structure LARGE INTEGER. 


Utiliseriez-vous une telle technique aujourd'hui? Probablement pas, mais si quel- 
qu'un avait besoin d'un type entier 128-bit, vous pourriez l'implémenter comme 
ceci. 


Aussi, inutile de dire, ceci fonctionne gráce au petit boutisme (2.2 on page 586) 
(toutes les architectures pour lesquelles Windows NT a été développé sont petit bou- 
tiste. Cette astuce n'est pas possible sur une architecture gros boutiste. 


1.36 SIMD 


SIMD est un acronyme: Single Instruction, Multiple Data (simple instruction, multiple 
données). 


Comme son nom le laisse entendre, cela traite des données multiples avec une seule 
instruction. 


Comme le FPU, ce sous-systéme du CPU ressemble à un processeur séparé à l'inté- 
rieur du x86. 


SIMD a commencé avec le MMX en x86. 8 nouveaux registres apparurent: MMO-MM7. 


Chaque registre MMX contient 2 valeurs 32-bit, 4 valeurs 16-bit ou 8 octets. Par 
exemple, il est possible d'ajouter 8 valeurs 8-bit (octets) simultanément en ajoutant 
deux valeurs dans des registres MMX. 


Un exemple simple est un éditeur graphique qui représente une image comme un 
tableau à deux dimensions. Lorsque l'utilisateur change la luminosité de l'image, 
l'éditeur doit ajouter ou soustraire un coefficient à/de chaque valeur du pixel. Dans 
un soucis de concision, si l'on dit que l'image est en niveau de gris et que chaque 
pixel est défini par un octet de 8-bit, alors il est possible de changer la luminosité de 
8 pixels simultanément. 
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A propos, c'est la raison pour laquelle les instructions de saturation sont présentes 
en SIMD. 


Lorsque l'utilisateur change la luminosité dans l'éditeur graphique, les dépassements 
au dessus ou en dessous ne sont pas souhaitables, donc il y a des instructions d'ad- 
dition en SIMD qui n'additionnent pas si la valeur maximum est atteinte, etc. 


Lorsque le MMX est apparu, ces registres étaient situés dans les registres du FPU. Il 
était seulement possible d'utiliser soit le FPU ou soit le MMX. On peut penser qu'Intel 
économisait des transistors, mais en fait, la raison d'une telle symbiose était plus 
simple —les anciens OSes qui n'étaient pas au courant de ces registres supplémen- 
taires et ne les sauvaient pas lors du changement de contexte, mais sauvaient les 
registres FPU. Ainsi, CPU avec MMX + ancien OS + processus utilisant les capacités 
MMX fonctionnait toujours. 


SSE—est une extension des registres SIMD à 128 bits, maintenant séparé du FPU. 
AVX—une autre extension, à 256 bits. 
Parlons maintenant de l'usage pratique. 


Bien sûr, il s'agit de routines de copie en mémoire (memcpy), de comparaison de 
mémoire (memcmp) et ainsi de suite. 


Un autre exemple: l'algorithme de chiffrement DES prend un bloc de 64-bit et une clef 
de 56-bit, chiffre le bloc et produit un résultat de 64-bit. L'algorithme DES peut étre 
considéré comme un grand circuit électronique, avec des fils et des portes AND/OR/- 
NOT. 


Le bitslice DESY? —est l'idée de traiter des groupes de blocs et de clés simultané- 
ment. Disons, une variable de type unsigned int en x86 peut contenir jusqu'à 32-bit, 
donc il est possible d'y stocker des résultats intermédiaires pour 32 paires de blocs- 
clé simultanément, en utilisant 644-56 variables de type unsigned int. 


Il existe un utilitaire pour brute-forcer les mots de passe/hashes d'Oracle RDBMS 
(certains basés sur DES) en utilisant un algorithme bitslice DES légérement modifié 
pour SSE2 et AVX—maintenant il est possible de chiffrer 128 ou 256 paires de blocs- 
clé simultanément. 


http://conus.info/utils/ops SIMD/ 


1.36.1 Vectorisation 


La vectorisation!?!, c'est lorsque, par exemple, vous avez une boucle qui prend une 
paire de tableaux en entrée et produit un tableau. Le corps de la boucle prend les 
valeurs dans les tableaux en entrée, fait quelque chose et met le résultat dans le 
tableau de sortie. La vectorisation est le fait de traiter plusieurs éléments simulta- 
nément. 


La vectorisation n'est pas une nouvelle technologie: l'auteur de ce livre l'a vu au 
moins sur la série du super-calculateur Cray Y-MP de 1988 lorsqu'il jouait avec sa 


170http://www.darkside.com.au/bitslice/ 
171Wikipédia: vectorisation 
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version «lite » le Cray Y-MP EL?/. 


Par exemple: 


for (i = 0; i < 1024; i++) 


Cli] = A[i]*B[i]; 


Ce morceau de code prend des éléments de A et de B, les multiplie et sauve le 
résultat dans C. 


Si chaque élément du tableau que nous avons est un int 32-bit, alors il est possible 
de charger 4 éléments de A dans un registre XMM 128-bit, 4 de B dans un autre 
registre XMM, et en exécutant PMULLD (Multiply Packed Signed Dword Integers and 
Store Low Result) et PMULHW (Multiply Packed Signed Integers and Store High Result), 
il est possible d’obtenir 4 produits 64-bit en une fois. 


Ainsi, le nombre d’exécution du corps de la boucle est 1024/4 au lieu de 1024, ce qui 
est 4 fois moins et, bien sûr, est plus rapide. 


Exemple d’addition 


Certains compilateurs peuvent effectuer la vectorisation automatiquement dans des 
cas simples, e.g., Intel C++173. 


Voici une fonction minuscule: 


int f (int sz, int *arl, int *ar2, int *ar3) 


1 
for (int i20; i<sz; i++) 
ar3[il=ar1[il+ar2[i]; 
return 0; 
}; 
Intel C++ 


Compilons la avec Intel C++ 11.1.051 win32: 
icl intel.cpp /QaxSSE2 /Faintel.asm /0x 


Nous obtenons (dans IDA) : 


; int cdecl f(int, int *, int *, int *) 
public ?f@@YAHHPAHO0@Z 
? F@@YAHHPAHOO@Z proc near 


var 10 
SZ 


dword ptr -10h 
dword ptr 4 


172A distance. Il est installé dans le musée des super-calculateurs: http://www. cray-cyber.org 
173Sur la vectorisation automatique d’Intel C++: Extrait: Vectorisation automatique efficace 
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arl 
ar2 
ar3 


loc 36: 


loc 55: 


loc 67: 


loc 7F: 


dword 
dword 
dword 


; CODE 


; CODE 


; CODE 


ptr 8 

ptr OCh 

ptr 10h 

edi 

esi 

ebx 

esi 

edx, [esp+10h+sz] 
edx, edx 

loc 15B 

eax, [esp+10h+ar3] 
edx, 6 

loc_143 


eax, [esp+10h+ar2] 
short loc_36 

esi, [esp+10h+ar2] 
esi, eax 

ecx, ds:0[edx*4] 
esi 

ecx, esi 

short loc_55 


XREF: f(int,int *,int *,int 
eax, [esp+10h+ar2] 

loc_143 

esi, [esp+10h+ar2] 

esi, eax 

ecx, ds:O[edx*4] 

esi, ecx 

loc_143 


XREF: f(int,int *,int *,int 
eax, [esp*10h«ar1] 

short loc_67 

esi, [esp*10h«ar1] 

esi, eax 

esi 

ecx, esi 

short loc 7F 


XREF: f(int,int *,int *,int 
eax, [esp*10h«ar1] 

loc 143 

esi, [esp*10h«ar1] 

esi, eax 

esi, ecx 

loc 143 


XREF: f(int,int *,int *,int 
edi, eax ; edi = ar3 


edi, OFh ; est-ce que ar3 est aligné sur 16-octets? 


short loc 9A ; oui 


*)+21 


*)+34 


*)+59 


*) +65 
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test edi, 3 


jnz loc_162 
neg edi 

add edi, 10h 
shr edi, 2 


loc 9A: ; CODE XREF: f(int,int *,int *,int *)+84 


lea ecx, [edi+4] 

cmp edx, ecx 

jl loc_162 

mov ecx, edx 

sub ecx, edi 

and ecx, 3 

neg ecx 

add ecx, edx 

test edi, edi 

jbe short loc D6 

mov ebx, [esp+10h+ar2] 
mov [esp+10h+var_10], ecx 
mov ecx, [esp*10h«ar1] 
xor esi, esi 


loc C1: ; CODE XREF: f(int,int *,int *,int *)+CD 


mov edx, [ecx+esi*4] 

add edx, [ebx+esi*4] 

mov [eax+esi*4], edx 

inc esi 

cmp esi, edi 

jb short loc C1 

mov ecx, [esp+10h+var 10] 
mov edx, [esp+10h+sz] 


loc D6: ; CODE XREF: f(int,int *,int *,int *)+B2 


mov esi, [esp+10h+ar2] 

lea esi, [esi+edi*4] ; est-ce que ar2+i*4 est aligné sur 
16-octets? 

test esi, OFh 

jz short loc 109 ; oui! 

mov ebx, [esp+10h+ar1] 

mov esi, [esp+10h+ar2] 


loc ED: ; CODE XREF: f(int,int *,int *,int *)+105 
movdqu xmml, xmmword ptr [ebx+edi*4] ; arl+i*4 


movdqu xmmO, xmmword ptr [esi+edi*4] ; ar2+i*4 n'est pas aligné sur 


16-octet, donc le charger dans XMMO 
paddd . xmml, xmm0 
movdqa xmmword ptr [eax+edi*4], xmml ; ar3+i*4 


add edi, 4 

cmp edi, ecx 

jb short loc ED 
jmp short loc 127 


loc 109: ; CODE XREF: f(int,int *,int *,int *)+E3 
mov ebx, [esp+10h+ar1] 
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mov esi, [esp+10h+ar2] 


loc 111: ; CODE XREF: f(int,int *,int *,int *)+125 
movdqu xmm0, xmmword ptr [ebx+edi*4] 
paddd xmm0, xmmword ptr [esi+edi*4] 
movdqa xmmword ptr [eax+edi*4], xmm0 


add edi, 4 
cmp edi, ecx 
jb short loc 111 


loc 127: ; CODE XREF: f(int,int *,int *,int *)+107 
; f(int,int *,int *,int *)+164 


cmp ecx, edx 

jnb short loc 15B 

mov esi, [esp*10h«ar1] 
mov edi, [esp+10h+ar2] 


loc 133: ; CODE XREF: f(int,int *,int *,int *)+13F 


mov ebx, [esi+ecx*4] 
add ebx, [edi+ecx*4] 
mov [eax+ecx*4], ebx 
inc ecx 

cmp ecx, edx 

jb short loc 133 
jmp short loc 15B 


loc 143: ; CODE XREF: f(int,int *,int *,int *)+17 
; f(int,int *,int *,int *)+3A ... 


mov esi, [esp*10h«ar1] 
mov edi, [esp+10h+ar2] 
xor ecx, ecx 


loc 14D: ; CODE XREF: f(int,int *,int *,int *)+159 


mov ebx, [esi+ecx*4] 
add ebx, [edi+ecx*4] 
mov [eax+ecx*4], ebx 
inc ecx 

cmp ecx, edx 

jb short loc 14D 


loc 15B: ; CODE XREF: f(int,int *,int *,int *)+A 
; f(int,int *,int *,int *)+129 ... 


xor eax, eax 
pop ecx 

pop ebx 

pop esi 

pop edi 

retn 


loc 162: ; CODE XREF: f(int,int *,int *,int *)+8C 
; f(int,int *,int *,int *)+9F 
xor ecx, ecx 
jmp short loc 127 
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? F@@YAHHPAHOO@Z endp 


Les instructions relatives a SSE2 sont: 


* MOVDQU (Move Unaligned Double Quadword déplacer double quadruple mot non 
alignés)—charge juste 16 octets depuis la mémoire dans un registre XMM. 


PADDD (Add Packed Integers ajouter entier packé)—ajoute 4 paires de nombres 
32-bit et laisse le résultat dans le premier opérande. A propos, aucune exception 
n'est levée en cas de débordement et aucun flag n'est mis, seuls les 32-bit bas 
du résultat sont stockés. Si un des opérandes de PADDD est l'adresse d'une 
valeur en mémoire, alors l'adresse doit étre alignée sur une limite de 16 octets. 
Si elle n'est pas alignée, une exception est levée. 


MOVDQA (Move Aligned Double Quadword) est la méme chose que MOVDQU, mais 
nécessite que l'adresse de la valeur en mémoire soit alignée sur une limite de 
16 octets. Si elle n'est pas alignée, une exception est levée. MOVDQA fonctionne 
plus vite que MOVDQU, mais nécessite la condition qui vient d'étre écrite. 


Donc, ces instructions SSE2 sont exécutées seulement dans le cas oü il y a plus de 
4 paires à traiter et que le pointeur ar3 est aligné sur une limite de 16 octets. 


Ainsi, si ar2 est également aligné sur une limite de 16 octets, ce morceau de code 
sera exécuté: 


movdqu xmmQ, xmmword ptr [ebx+edi*4] ; arl+i*4 
paddd xmm0, xmmword ptr [esi+edi*4] ; ar2+i*4 
movdqa xmmword ptr [eax+edi*4], xmm0 ; ar3+i*4 


Autrement, la valeur de ar2 est chargée dans XMMO avec MOVDQU, qui ne nécessite 
pas que le pointeur soit aligné, mais peut s'exécuter plus lentement. 


movdqu xmml, xmmword ptr [ebx+edi*4] ; arl+i*4 

movdqu xmmO, xmmword ptr [esi+edi*4] ; ar2+i*4 n'est pas aligné sur 
16-octet, donc le charger dans XMMO 

paddd xmml, xmm0 

movdqa xmmword ptr [eax+edi*4], xmml ; ar3+i*4 


Dans tous les autres cas, le code non-SSE2 sera exécuté. 


GCC 


174 


GCC peut aussi vectoriser dans des cas simples*”*, si l'option -03 est utilisée et le 


support de SSE2 activé: -msse2. 


Ce que nous obtenons (GCC 4.4.1) : 


; f(int, int *, int *, int *) 
public Z1fiPiS S. 
_Z1fiPiS S proc near 


174plus sur le support de la vectorisation dans GCC: http://gcc.gnu.org/projects/tree-ssa/ 
vectorization.html 
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var_18 
var_14 
var_10 
arg_0 
arg_4 
arg_8 
arg C 


loc 80484C1: 


loc 80484C8: 


loc 80484D8: 


loc 80484E8: 


dword ptr -18h 
dword ptr -14h 
dword ptr -10h 
dword ptr 8 

dword ptr OCh 
dword ptr 10h 
dword ptr 14h 


push ebp 

mov ebp, esp 

push edi 

push esi 

push ebx 

sub esp, OCh 

mov ecx, [ebp+arg 0] 
mov esi, [ebptarg 4] 
mov edi, [ebp+arg 8] 
mov ebx, [ebp«arg C] 
test ecx, ecx 

jte short loc 80484D8 
cmp ecx, 6 

lea eax, [ebx+10h] 

ja short loc 80484E8 


; CODE XREF: f(int,int *,int *,int *)+4B 
; f(int,int *,int *,int *)+61 ... 


xor eax, eax 
nop 
lea esi, [esi+0] 


; CODE XREF: f(int,int *,int *,int *)+36 


mov edx, [edi+eax*4] 

add edx, [esiteax*4] 

mov [ebx+eax*4], edx 

add eax, 1 

cmp eax, ecx 

jnz short loc 80484C8 


; CODE XREF: f(int,int *,int *,int *)+17 
; f(int,int *,int *,int *)+A5 


add esp, OCh 
xor eax, eax 
pop ebx 

pop esi 

pop edi 

pop ebp 

retn 

align 8 


; CODE XREF: f(int,int *,int *,int *)+1F 
test bl, OFh 
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loc 80484F8: 


loc 8048503: 


loc 8048520: 


loc 8048547: 


loc 8048558: 


jnz short loc 80484C1 
lea edx, [esi+10h] 
cmp ebx, edx 
jbe loc 8048578 
; CODE XREF: f(int,int *,int *,int *)+E0 
lea edx, [edi+10h] 
cmp ebx, edx 
ja short loc 8048503 
cmp edi, eax 
jbe short loc 80484C1 
; CODE XREF: f(int,int *,int *,int *)+5D 
mov eax, ecx 
shr eax, 2 
mov [ebp+var 14], eax 
shl eax, 2 
test eax, eax 
mov [ebp+var_10], eax 
jz short loc 8048547 
mov [ebp+var 18], ecx 
mov ecx, [ebp+var 14] 
xor eax, eax 
xor edx, edx 
nop 


; CODE XREF: f(int,int *,int *,int *)+9B 
movdqu xmml, xmmword ptr [edi+eax] 
movdqu xmm0, xmmword ptr [esi+eax] 
add edx, 1 
paddd xmm0, xmml 
movdga xmmword ptr [ebx+eax], xmm0 
add eax, 10h 


cmp edx, ecx 

jb short loc_8048520 

mov ecx, [ebp+var_18] 

mov eax, [ebp+var_10] 

cmp ecx, eax 

jz short loc 80484D8 
; CODE XREF: f(int,int *,int *,int *)+73 

lea edx, ds:0[eax*4] 

add esi, edx 

add edi, edx 

add ebx, edx 

lea esi, [esi+0] 


; CODE XREF: f(int,int *,int *,int *)+CC 


mov edx, [edi] 
add eax, 1 
add edi, 4 
add edx, [esi] 


add esi, 4 
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mov [ebx], edx 
add ebx, 4 

cmp ecx, eax 
jg short loc 8048558 
add esp, OCh 
xor eax, eax 
pop ebx 

pop esi 

pop edi 

pop ebp 

retn 


loc 8048578: ; CODE XREF: f(int,int *,int *,int *)+52 


cmp eax, esi 
jnb loc 80484C1 
jmp loc 80484F8 


_Z1fiPiS S endp 


Presque le méme, toutefois, pas aussi méticuleux qu'Intel C++. 


Exemple de copie de mémoire 


Revoyons le simple exemple memcpy() (1.22.2 on page 256): 


#include <stdio.h> 


void my memcpy (unsigned char* dst, unsigned char* src, size t cnt) 
1 
size t i; 
for (i20; i«cnt; i++) 
dst[il=src[i]; 
}; 


Et ce que les optimisations de GCC 4.9.1 font: 
Listing 1.396 : GCC 4.9.1 x64 avec optimisation 


my_memcpy: 
: RDI = adresse de destination 
: RSI = adresse source 
; RDX = taille du bloc 

test rdx, rdx 

je .L41 

lea rax, [rdi+16] 

cmp rsi, rax 

lea rax, [rsi+16] 

setae cl 

cmp rdi, rax 

setae al 

or cl, al 

je .L13 

cmp rdx, 22 


jbe .L13 
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mov 
push 
push 
neg 
and 
cmp 
cmova 
xor 
test 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 


rcx, 
rbp 
rbx 
rcx 
ecx, 
rcx, 
rcx, 
eax, 
rcx, 
.L4 
eax, 
rcx, 
BYTE 
.L15 
eax, 
rcx, 
BYTE 
.L16 
eax, 
rcx, 
BYTE 
.L17 
eax, 
rcx, 
BYTE 
.L18 
eax, 
rcx, 
BYTE 
.L19 
eax, 
rcx, 
BYTE 
.L20 
eax, 
rcx, 
BYTE 
.L21 
eax, 
rcx, 
BYTE 
.L22 
eax, 
rcx, 
BYTE 
.L23 
eax, 
rcx, 
BYTE 
.L24 
eax, 
rcx, 
BYTE 


rsi 


15 

rdx 
rdx 
eax 
rcx 


BYTE PTR [rsi] 
1 
PTR [rdi], al 


BYTE PTR [rsi+1] 
2 
PTR [rdi+1], al 


BYTE PTR [rsi+2] 
3 
PTR [rdi+2], al 


BYTE PTR [rsi+3] 
4 
PTR [rdi+3], al 


BYTE PTR [rsi+4] 
5 
PTR [rdi+4], al 


BYTE PTR [rsi+5] 
6 
PTR [rdi+5], al 


BYTE PTR [rsi+6] 
7 
PTR [rdi+6], al 


BYTE PTR [rsi+7] 
8 
PTR [rdi+7], al 


BYTE PTR [rsi+8] 
9 
PTR [rdi+8], al 


BYTE PTR [rsi+9] 
10 
PTR [rdi+9], al 


BYTE PTR [rsi+10] 
11 
PTR [rdi+10], al 
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.L4: 


.L7: 


.L6: 


je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
je 
movzx 
cmp 
mov 
jne 
movzx 
mov 
mov 


mov 
lea 
sub 
lea 
sub 
shr 
add 
mov 
sal 
cmp 
jbe 
lea 
xor 
add 
xor 


movdqa 
add 
movups 
add 


.L25 

eax, BYTE PTR [rsi+11] 
rcx, 12 

BYTE PTR [rdi+11], al 
.L26 

eax, BYTE PTR [rsi+12] 
rcx, 13 

BYTE PTR [rdi+12], al 
.L27 

eax, BYTE PTR [rsi+13] 
rcx, 15 

BYTE PTR [rdi+13], al 
.L28 

eax, BYTE PTR [rsi+14] 
BYTE PTR [rdi+14], al 
eax, 15 


r10, rdx 

r9, [rdx-1] 
r10, rcx 

r8, [r10-16] 
r9, rcx 

r8, 4 

r8, 1 

r11, r8 

rll, 4 

r9, 14 

.L6 

rbp, [rsi+rcx] 
r9d, rod 
rcx, rdi 
ebx, ebx 


xmm0, XMMWORD PTR [rbp+0+r9] 
rbx, 1 
XMMWORD PTR [rcx+r9], xmm0 


r9, 16 
rbx, r8 
.L7 

rax, r11 
r10, r11 
.L1 


ecx, BYTE PTR [rsi+rax] 
BYTE PTR [rdi+rax], cl 
rcx, [rax+1] 

rdx, rcx 

.L1 

ecx, BYTE PTR [rsi+l+rax] 
BYTE PTR [rdi+l+rax], cl 
rcx, [rax+2] 

rdx, rcx 

.L1 
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movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 
cmp 
jbe 
movzx 
mov 
lea 


ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 
rdx, 
.L1 
ecx, 
BYTE 
rcx, 


BYTE PTR [rsi+2+rax] 
PTR [rdi+2+rax], cl 
[rax+3] 

rcx 


BYTE PTR [rsi+3+rax] 
PTR [rdi+3+rax], cl 
[rax+4] 

rcx 


BYTE PTR [rsi+4+rax] 
PTR [rdi+4+rax], cl 
[rax+5] 

rcx 


BYTE PTR [rsi+5+rax] 
PTR [rdi+5+rax], cl 
[rax+6] 

rcx 


BYTE PTR [rsi+6+rax] 
PTR [rdi+6+rax], cl 
[rax+7] 

rcx 


BYTE PTR [rsi+7+rax] 
PTR [rdi+7+rax], cl 
[rax+8] 

rcx 


BYTE PTR [rsi+8+rax] 
PTR [rdi+8+rax], cl 
[rax+9] 

rcx 


BYTE PTR [rsi+9+rax] 
PTR [rdi+9+rax], cl 
[rax+10] 

rcx 


BYTE PTR [rsi+10+rax] 
PTR [rdi+10+rax], cl 
[rax+11] 

rcx 


BYTE PTR [rsi+11+rax] 
PTR [rdi+11+rax], cl 
[rax+12] 

rcx 


BYTE PTR [rsi+12+rax] 
PTR [rdi+12+rax], cl 
[rax+13] 
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.L1: 


.L41: 


.L13: 


.L3: 


.L28: 


.L15: 


.L16: 


.L17: 


.L18: 


.L19: 


.L20: 


.L21: 


.L22: 


.L23: 


cmp 
jbe 
MOVZX 
mov 
lea 
cmp 
jbe 
MOVZX 
mov 


pop 
pop 


rep ret 
xor 


MOVZX 
mov 
add 
cmp 
jne 
rep ret 


mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 


mov 
jmp 


rdx, 
.L1 

ecx, 
BYTE 
rcx, 
rdx, 
.L1 

edx, 
BYTE 


rbx 
rbp 


eax, 


ecx, 
BYTE 
rax, 
rax, 
.L3 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


eax, 
.L4 


rcx 


BYTE PTR [rsi+13+rax] 
PTR [rdi+13+rax], cl 
[rax+14] 

rcx 


BYTE PTR [rsi+14+rax] 
PTR [rdi+14+rax], dl 


eax 


BYTE PTR [rsi+rax] 
PTR [rdi+rax], cl 
1 

rdx 


14 
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.L24: 
mov eax, 10 
jmp .L4 
.L25: 
mov eax, 11 
jmp .L4 
.L26: 
mov eax, 12 
jmp .L4 
.L27: 
mov eax, 13 
jmp .L4 


1.36.2 Implémentation SIMD de strlen() 


Il faut noter que les instructions SIMD peuvent étre insérées en code C/C++ via des 
macros?”° spécifiques. Pour MSVC, certaines d'entre elles se trouvent dans le fichier 


intrin.h. 


Il est possible d'implémenter la fonction strlen()+7° en utilisant des instructions 
SIMD qui fonctionne 2-2.5 fois plus vite que l'implémentation habituelle. Cette fonc- 
tion charge 16 caractéres dans un registre XMM et teste chacun d'eux avec zéro. 
177 


size t strlen sse2(const char *str) 

1 
register size t len - 0; 
const char *s=str; 


bool str is aligned=(((unsigned int)str)&OxFFFFFFF0) == (unsigned int)? 


s str; 


if (str is aligned--false) 
return strlen (str); 


m128i xmm0 = mm setzero si128(); 
. m128i xmml; 
int mask = 0; 


for (;;) 

1 
xmm1 = mm load si128(( m128i *)s); 
xmml = mm cmpeq epi8(xmml, xmm0); 
if ((mask = mm movemask epi8(xmml)) ! 
1 


unsigned long pos; 
 BitScanForward(&pos, mask); 
len += (size t)pos; 


break; 


175MSDN: particularités MMX, SSE, et SSE2 


16strlen() —fonction de la bibliothèque C standard pour calculer la longueur d'une chaîne 
177L'exemple est basé sur le code source de: http://www.strchr.com/sse2 optimised strlen. 
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) 


S += sizeof( m128i); 


len += sizeof( m128i); 


}; 


return len; 


Compilons la avec MSVC 2010 avec l'option /0x : 


Listing 1.397 : MSVC 2010 avec optimisation 


_pos$75552 = -4 ; taille = 4 
_str$ = 8 ; taille = 4 
?strlen_sse2@@YAIPBD@Z PROC ; strlen sse2 

push ebp 

mov ebp, esp 

and esp, -16 ; fffffffOH 

mov eax, DWORD PTR str$[ebp] 

sub esp, 12 ; 0000000cH 

push esi 

mov esi, eax 

and esi, -16 ; fffffffOH 

xor edx, edx 

mov ecx, eax 

cmp esi, eax 

je SHORT $LN4@strlen_sse 

lea edx, DWORD PTR [eax+1] 

npad 3 ; aligner le prochain label 
$LL11@strlen sse: 

mov cl, BYTE PTR [eax] 

inc eax 

test cl, cl 

jne SHORT $LL11@strlen_sse 

sub eax, edx 

pop esi 

mov esp, ebp 

pop ebp 

ret 0 
$LNAGstrlen sse: 

movdqa xmm1, XMMWORD PTR [eax] 

pxor xmmO, xmm0 

pcmpeqb  xmml, xmm0 

pmovmskb eax, xmml 

test eax, eax 

jne SHORT $LN9Gstrlen sse 
$LL3Gstrlen sse: 

movdqa xmm1, XMMWORD PTR [ecx+16] 

add ecx, 16 ; 00000010H 

pcmpeqb  xmml, xmm0 

add edx, 16 ; 00000010H 

pmovmskb eax, xmml 

test eax, eax 
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je SHORT $LL3@strlen sse 
$LN9Gstrlen sse: 
bsf eax, eax 
mov ecx, eax 
mov DWORD PTR _pos$75552[esp+16], eax 
lea eax, DWORD PTR [ecx+edx] 
pop esi 
mov esp, ebp 
pop ebp 
ret 0 
?strlen_sse2@@YAIPBD@Z ENDP ; strlen sse2 


Comment est-ce que ca fonctionne? Premiérement, nous devons comprendre la but 
de la fonction. Elle calcule la longueur de la chaine C, mais nous pouvons utiliser 
différents termes: sa táche est de chercher l'octet zéro, et de calculer sa position 
relativement au début de la chaine. 


Premiérement, nous testons si le pointeur str est aligné sur une limite de 16 octets. 
Si non, nous appelons l'implémentation générique de strlen(). 


Puis, nous chargeons les 16 octets suivants dans le registre XMM1 en utilisant MOVDQA. 


Un lecteur observateur pourrait demander, pourquoi MOVDQU ne pourrait pas étre 
utilisé ici, puisqu'il peut charger des données depuis la mémoire quelque soit l'ali- 
gnement du pointeur? 


Oui, cela pourrait étre fait comme ca: si le pointeur est aligné, charger les données 
en utilisant MOVDQA, si non —utiliser MOVDQU moins rapide. 


Mais ici nous pourrions rencontrer une autre restriction: 


Dans la série d'OS Windows NT (mais pas seulement), la mémoire est allouée par 
pages de 4 KiB (4096 octets). Chaque processus win32 a 4GiB de disponible, mais 
en fait, seulement une partie de l'espace d'adressage est connecté à de la mémoire 
réelle. Si le processus accéde a un bloc mémoire absent, une exception est levée. 
C'est comme cela que fonctionnent les VM?78, 


Donc, une fonction qui charge 16 octets à la fois peut dépasser la limite d'un bloc 
de mémoire allouée. Disons que l'OS a alloué 8192 (0x2000) octets à l'adresse 
0x008c0000. Ainsi, le bloc comprend les octets démarrant à l'adresse 0x008c0000 
jusqu'à 0x008c1fff inclus. 


Aprés ce bloc, c'est à dire à partir de l'adresse 0x008c2000 il n'y a rien du tout, e.g. 
l'OS n'y a pas alloué de mémoire. Toutes tentatives d'accéder à la mémoire à partir 
de cette adresse va déclencher une exception. 


Et maintenant, considérons l'exemple dans lequel le programme posséde une chaíne 
contenant 5 caractéres presque à la fin d'un bloc, et ce n'est pas un crime. 


78 Wikipédia 
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Ox008c1ff8 | 'h' 
Ox008c1ff9 | 'e' 
Ox008clffa | ‘|’ 
Ox008c1ffb | ‘I’ 
Ox008clffc | 'o' 
0x008c1ffd | ‘\x00’ 
0x008c1ffe | random noise 
0x008c1fff | random noise 


Donc, dans des conditions normales, le programme appelle strlen(), en lui passant 
un pointeur sur la chaine 'hello' se trouvant en mémoire à l'adresse 0x008c1ff8. 
strlen() lit un octet à la fois jusqu'à O0x008c1ffd, où se trouve un octet à zéro, et 
puis s'arréte. 


Maintenant, si nous implémentons notre propre strlen() lisant 16 octets à la fois, 
à partir de n'importe quelle adresse, alignée ou pas, MOVDQU pourrait essayer de 
charger 16 octets à la fois depuis l'adresse 0x008c1ff8 jusqu'à 0x008c2008, et ainsi 
déclencherait une exception. Cette situation peut être évitée, bien sûr. 


Nous allons donc ne travailler qu'avec des adresses alignées sur une limite de 16 
Octets, ce qui en combinaison avec la connaissance que les pages de l'OS sont en 
général alignées sur une limite de 16 octets nous donne quelques garanties que 
notre fonction ne va pas lire de la mémoire non allouée. 


Retournons à notre fonction. 


mm setzero si128()—estune macro générant pxor xmm0, xmm0 —elle efface juste 
le registre XMMO. 


_mm load si128()—estune macro pour MOVDQA, elle charge 16 octets depuis l'adresse 
dans le registre XMM1. 


mm cmpeq epi8()—est une macro pour PCMPEQB, une instruction qui compare deux 
registres XMM par octet. 


Et si l'un des octets est égal à celui dans l'autre registre, il y aura Oxff à ce point 
dans le résultat ou 0 sinon. 


Par exemple: 


XMM1: 0x11223344556677880000000000000000 
XMMO: 0x11ab3444007877881111111111111111 


Aprés l'exécution de pcmpeqb xmm1, xmm0, le registre XMM1 contient: 
XMM1: OxffOOO00ffOO000ffff0000000000000000 


Dans notre cas, cette instruction compare chacun des 16 octets avec un bloc de 16 
octets à zéro, qui ont été mis dans le registre XMMO par pxor xmm0, Xmm0. 


La macro suivante est mn movemask epi8() —qui est l'instruction PMOVMSKB. 
Elle est trés utile avec PCMPEQB. 


pmovmskb eax, xmml 
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Cette instruction met d'abord le premier bit d'EAX a 1 si le bit le plus significatif du 
premier octet dans XMM1 est 1. En d'autres mots, si le premier octet du registre XMM1 
est Oxff, alors le premier bit de EAX sera 1 aussi. 


Si le second octet du registre XMM1 est Oxff, alors le second bit de EAX sera mis à 1 
aussi. En d'autres mots, cette instruction répond a la question «quels octets de XMM1 
ont le bit le plus significatif à 1 ou sont plus grand que 0x7f ? » et renvoie 16 bits 
dans le registre EAX. Les autres bits du registre EAX sont mis à zéro. 


À propos, ne pas oublier cette bizarrerie dans notre algorithme. Il pourrait y avoir 16 
octets dans l'entrée, comme: 


15 14 13 12 11 10 9 3 2 H 0 


'h'i'e' l7] 7010 déchets O déchets 


Il s'agit de la chaine 'hello', terminée par un zéro, et du bruit aléatoire dans la 
mémoire. 


Si nous chargeons ces 16 octets dans XMM1 et les comparons avec ceux à zéro dans 
XMM8, nous obtenons quelque chose comme ??? : 


XMM1: 0x0000ff00000000000000ff0000000000 


Cela signifie que cette instruction a trouvé deux octets à zéro, et ce n'est pas sur- 
prenant. 


PMOVMSKB dans notre cas va mettre EAX à 
0b0010000000100000. 


Bien súr, notre fonction doit seulement prendre le premier octet à zéro et ignorer le 
reste. 


L'instruction suivante est BSF (Bit Scan Forward). 


Cette instruction trouve le premier bit mis à 1 et met sa position dans le premier 
opérande. 


EAX-0b0010000000100000 


Aprés l'exécution de bsf eax, eax, EAX contient 5, signifiant que 1 a été trouvé au 
bit d'index 5 (en commencant à zéro). 


MSVC a une macro pour cette instruction: BitScanForward. 


Maintenant c'est simple. Si un octet à zéro a été trouvé, sa position est ajoutée à ce 
que nous avions déjà compté et nous pouvons renvoyer le résultat. 


Presque tout. 


À propos, il faut aussi noter que le compilateur MSVC a généré deux corps de boucle 
cóte-à-cóte, afin d'optimiser. 


Et aussi, SSE 4.2 (apparu dans les Intel Core i7) offre encore plus d'instructions avec 
lesquelles ces manipulations de chaîne sont encore plus facile: http: //www.strchr. 
com/strcmp and strlen using sse 4.2 


179Un ordre de MSB à LSB189 est utilisé ici. 


544 


1.37 64 bits 
1.37.1 x86-64 


Il s'agit d'une extension à 64 bits de l'architecture x86. 


Pour l'ingénierie inverse, les changements les plus significatifs sont: 


La plupart des registres (à l'exception des registres FPU et SIMD) ont été éten- 
dus à 64 bits et leur nom préfixé de la lettre R. 8 registres ont également été 
ajoutés. Les GPR sont donc désormais: RAX, RBX, RCX, RDX, RBP, RSP, RSI, RDI, 
R8, R9, R10, R11, R12, R13, R14, R15. 


Les anciens registres restent accessibles de la maniére habituelle. Ainsi, l'utili- 
sation de EAX donne accés aux 32 bits de poids faible du registre RAX : 


Octet d'indice 
716 51413121 0 
RAX* 


AH | AL 


Les nouveaux registres R8-R15 possèdent eux aussi des sous-parties : RaD-R15D 
(pour les 32 bits de poids faible), R8W-R15W (16 bits de poids faible), R8L-R15L 
(8 bits de poids faible). 


Octet d'indice 
716 5|4|3|2|1|0 
R8 


R8D 
R8W 
R8L 


Les registres SIMD ont vu leur nombre passé de 8 à 16: XMMO-XMM15. 


En environnement Win64, la convention d'appel de fonctions est légérement dif- 
férente et ressemble à la convention fastcall (6.1.3 on page 955). Les 4 premiers 
arguments sont stockés dans les registres RCX, RDX, R8 et R9. Les arguments 
suivants —sur la pile. La fonction appelante doit également allouer 32 octets 
pour utilisation par la fonction appelée qui pourra y sauvegarder les registres 
contenant les 4 premiers arguments. Les fonctions les plus simples peuvent uti- 
liser les arguments directement depuis les registres. En revanche, les fonctions 
plus complexes peuvent sauvegarder ces registres sur la pile. 


L'ABI System V AMD64 (Linux, *BSD, Mac OS X)[Michael Matz, Jan Hubicka, An- 
dreas Jaeger, Mark Mitchell, System V Application Binary Interface. AMD64 Ar- 
chitecture Processor Supplement, (2013)] ‘ressemble elle aussi à la conven- 
tion fastcall. Elle utilise 6 registres RDI, RSI, RDX, RCX, R8, R9 pour les 6 premiers 
arguments. Tous les suivants sont passés sur la pile. 


l8lAussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64-abi.pdf 
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Référez-vous également à la section sur les conventions d'appel (6.1 on page 953). 


* Pour des raisons de compatibilité, le type C/C++ int conserve sa taille de 32bits. 
* Tous les pointeurs sont désormais sur 64 bits. 


Dans la mesure oü le nombre de registres a doublé, les compilateurs disposent de 
plus de marge de manœuvre en matière d'allocation des registres. Pour nous, il en 
résulte que le code généré contient moins de variables locales. 


Par exemple, la fonction qui calcule la premiére S-box de l'algorithme de chiffrage 
DES traite en une fois au moyen de la méthode DES bitslice des valeurs de 32/64/128/256 
bits (en fonction dutype DES type (uint32, uint64, SSE2 or AVX)). Pour en savoir plus 
sur cette technique, voyez (1.36 on page 526): 


Generated S-box files. 


* 
* 

* This software may be modified, redistributed, and used for any purpose, 
* so long as its origin is acknowledged. 
* 
* 


Produced by Matthew Kwan - March 1998 


#ifdef WIN64 

#define DES type unsigned  int64 
ttelse 

#define DES type unsigned int 
#endif 


void 

sl ( 
DES type al, 
DES type a2, 
DES type a3, 
DES type a4, 
DES type a5, 
DES type ab, 
DES type *outl, 
DES type *out2, 
DES type *out3, 
DES type *out4 


DES type x1, x2, x3, x4, x5, x6, x7, x8; 

DES type x9, x10, x11, x12, x13, x14, x15, x16; 
DES type x17, x18, x19, x20, x21, x22, x23, x24; 
DES type X25, x26, x27, x28, x29, x30, x31, x32; 
DES type x33, x34, x35, x36, x37, x38, x39, x40; 
DES type X41, x42, x43, x44, x45, x46, x47, x48; 
DES type x49, x50, x51, x52, x53, x54, x55, x56; 


xl = a3 & -a5; 
x2 = x1 ^ a4; 
x3 = a3 & ~a4; 
x4 = x3 | a5; 
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Won HW H H H H H H H H PH H NOH H H H H Hg H H H Hm H gH i 


X X X 
WwW wo 
NOC 
ct 
AB 


x38 
x39 


x X X X X X x 
RARRBRARRA 
O U1 UNO 


*ou 


X OX KK X X XK 
UU U1 U1 B ps 
QJ N H © (o OO - 


x54 


t 


uo n gu Hn Hu A dt e2»o H m ot H H m O db ob I! I 


a3 | x31; 
x24 & -x37; 
x41 | x3; 
x42 & ~a2; 
x40 ^ x43; 
al & -x44; 
x39 ^ -x45; 
“= x46; 

x33 & -x9; 
x47 ^ x39; 
x4 ^ x36; 
x49 € ~x5; 
x42 | x18; 
x51 ^ a5; 
a2 & ~x52; 
x50 ^ x53; 
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*ou 


=a 
= X 
t3. ^ 


1 | x54; 
48 ^ ~x55; 
= x56; 


Cette fonction contient de nombreuses variables locales, mais toutes ne se retrou- 


veront pas dans la pile. Compilons ce fichier avec MSVC 2008 et l'option /0x : 


Listing 1.398 : MSVC 2008 avec optimisation 


size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 
size 


Hon m g H gH H dod H Ho gp td og H H H ud gp dea 
EE ES ESE ESE ESSE SS 


size 


; 00000014H 
PTR _a5$[esp+16] 
PTR _a4$[esp+20] 


PTR _a3$[esp+28] 


PTR _a5$[esp+32] 


PUBLIC _sl 
; Function compile flags: /Ogtpy 
_ TEXT SEGMENT 
_x6$ = -20 $ 
_x3$ = -16 ; 
_x1$ = -12 : 
_x8$ = -8 ; 
_X4$ = -4 ; 
al$ = 8 | 
_a2$ = 12 ; 
83$ - 16 ; 
x33$ = 20 ; 
x7$ = 20 ; 
a4$ - 20 ; 
_a5$ = 24 ; 
tv326 = 28 ; 
_X36$ = 28 ; 
x28$ = 28 ; 
_a6$ = 28 ; 
_out1$ = 32 ; 
_x24$ = 36 ; 
_out2$ = 36 ; 
_out3$ = 40 ; 
_out4$ = 44 ; 
sl PROC 
sub esp, 20 
mov edx, DWORD 
push ebx 
mov ebx, DWORD 
push ebp 
push esi 
mov esi, DWORD 
push edi 
mov edi, ebx 
not edi 
mov ebp, edi 
and edi, DWORD 
mov ecx, edx 
not ecx 
and ebp, esi 
mov eax, ecx 
and eax, esi 
and ecx, ebx 
mov DWORD PTR . 


x1$[esp+36], eax 
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xor 
mov 
or 

mov 
and 
mov 
mov 
xor 
mov 
mov 
xor 
mov 
xor 
mov 
and 
mov 
mov 
xor 
or 

not 
and 
xor 
mov 
or 

mov 
mov 
xor 
and 
mov 
xor 
not 
or 

xor 
mov 
mov 
xor 
not 
xor 
and 
mov 
mov 
or 

mov 
or 

mov 
xor 
mov 
xor 
not 
and 
mov 
and 
xor 


eax, ebx 

esi, ebp 

esi, edx 

DWORD PTR _x4$[esp+36], esi 
esi, DWORD PTR _a6$[esp+32] 
DWORD PTR _x7$[esp+32], ecx 
edx, esi 

edx, eax 

DWORD PTR _x6$[esp+36], edx 
edx, DWORD PTR _a3$[esp+32] 
edx, ebx 

ebx, esi 

ebx, DWORD PTR _a5$[esp+32] 
DWORD PTR _x8$[esp+36], edx 
ebx, edx 

ecx, edx 

edx, ebx 

edx, ebp 

edx, DWORD PTR _a6$[esp+32] 
ecx 

ecx, DWORD PTR _a6$[esp+32] 
edx, edi 

edi, edx 

edi, DWORD PTR _a2$[esp+32] 
DWORD PTR _x3$[esp+36], ebp 
ebp, DWORD PTR _a2$[esp+32] 
edi, ebx 

edi, DWORD PTR _al$[esp+32] 
ebx, ecx 

ebx, DWORD PTR _x7$[esp+32] 
edi 

ebx, ebp 

edi, ebx 

ebx, edi 

edi, DWORD PTR _out2$[esp+32] 
ebx, DWORD PTR [edi] 

eax 

ebx, DWORD PTR _x6$[esp+36] 
eax, edx 

DWORD PTR [edi], ebx 

ebx, DWORD PTR _x7$[esp+32] 
ebx, DWORD PTR _x6$[esp+36] 
edi, esi 

edi, DWORD PTR _x1$[esp+36] 
DWORD PTR _x28$[esp+32], ebx 
edi, DWORD PTR _x8$[esp+36] 
DWORD PTR _x24$[esp+32], edi 
edi, ecx 

edi 

edi, edx 

ebx, edi 

ebx, ebp 

ebx, DWORD PTR _x28$[esp+32] 
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xor 
not 
mov 
and 
and 
xor 
mov 
xor 
xor 
mov 
mov 
and 
mov 
or 

mov 
not 
and 
or 

xor 
not 
and 
not 
or 

not 
and 
or 

xor 
mov 
xor 
xor 
mov 
not 
and 
not 
and 
and 
xor 
or 

not 
xor 
not 
and 
xor 
not 
mov 
xor 
mov 
xor 
pop 
pop 
xor 
pop 
mov 


ebx, eax 

eax 

DWORD PTR _x33$[esp+32], ebx 
ebx, DWORD PTR _al$[esp+32] 
eax, ebp 

eax, ebx 

ebx, DWORD PTR _out4$[esp+32] 
eax, DWORD PTR [ebx] 

eax, DWORD PTR _x24$[esp+32] 
DWORD PTR [ebx], eax 

eax, DWORD PTR _x28$[esp+32] 
eax, DWORD PTR _a3$[esp+32] 
ebx, DWORD PTR _x3$[esp+36] 
edi, DWORD PTR _a3$[esp+32] 
DWORD PTR _x36$[esp+32], eax 
eax 

eax, edx 

ebx, ebp 

ebx, eax 

eax 

eax, DWORD PTR _x24$[esp+32] 
ebp 

eax, DWORD PTR _x3$[esp+36] 
esi 

ebp, eax 

eax, edx 

eax, DWORD PTR _a5$[esp+32] 
edx, DWORD PTR _x36$[esp+32] 
edx, DWORD PTR _x4$[esp+36] 
ebp, edi 

edi, DWORD PTR _out1$[esp+32] 
eax 

eax, DWORD PTR _a2$[esp+32] 
ebp 

ebp, DWORD PTR _al$[esp+32] 
edx, esi 

eax, edx 

eax, DWORD PTR _al$[esp+32] 
ebp 

ebp, DWORD PTR [edi] 

ecx 

ecx, DWORD PTR _x33$[esp+32] 
ebp, ebx 

eax 

DWORD PTR [edi], ebp 

eax, ecx 

ecx, DWORD PTR _out3$[esp+32] 
eax, DWORD PTR [ecx] 

edi 

esi 

eax, ebx 

ebp 

DWORD PTR [ecx], eax 
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pop ebx 
add esp, 20 
ret 0 

_sl ENDP 


Seules 5 variables ont été allouées dans la pile par le compilateur. 


Essayons maintenant une compilation avec la version 64 bits de MSVC 2008: 


Listing 1.399 : MSVC 2008 avec optimisation 


al$ 
a2$ 


"ow gy d 
o 
Az 


x36$1$ = 88 


a6$ = 96 

104 
112 
120 
128 
sl PROC 


mov QWORD PTR [rsp+24], rbx 
mov QWORD PTR [rsp+32], rbp 
mov QWORD PTR [rsp+16], rdx 
mov QWORD PTR [rsp+8], rcx 


push rsi 
push rdi 
push r12 
push r13 
push r14 
push r15 


mov r15, QWORD PTR a5$[rsp] 
mov rcx, QWORD PTR a6$[rsp] 


mov rbp, r8 
mov r10, r9 
mov rax, r15 
mov rdx, rbp 
not rax 

xor rdx, r9 
not r10 

mov rll, rax 
and rax, r9 
mov rsi, r10 


mov QWORD PTR x36$1$[rsp], rax 
and r11, r8 


and rsi, r8 
and r10, r15 
mov r13, rdx 
mov rbx, r11 
xor rbx, r9 


mov r9, QWORD PTR a2$[rsp] 
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mov 
or 

not 
and 
mov 
and 
mov 
mov 
xor 
xor 
not 
and 
mov 
xor 
or 

xor 
and 
mov 
or 

xor 
mov 
xor 
and 
or 

not 
xor 
mov 
xor 
xor 
mov 
mov 
mov 
or 

or 

mov 
xor 
mov 
mov 
mov 
xor 
not 
and 
mov 
and 
xor 
xor 
not 
and 
mov 
and 
xor 
mov 
xor 


r12, rsi 
r12, r15 
r13 

r13, rcx 
r14, r12 
r14, rcx 
rax, r14 
r8, r14 

r8, rbx 

rax, r15 
rbx 

rax, rdx 
rdi, rax 
rdi, rsi 
rdi, rcx 
rdi, r10 
rbx, rdi 
rcx, rdi 
rcx, r9 

rcx, rax 
rax, r13 


rax, QWORD PTR x36$1$[rsp] 
rcx, QWORD PTR al$[rsp] 
rax, r9 

rcx 

rcx, rax 

rax, QWORD PTR out2$[rsp] 
rcx, QWORD PTR [rax] 

rcx, r8 

QWORD PTR [rax], rcx 

rax, QWORD PTR x36$1$[rsp] 
rcx, r14 

rax, r8 

rcx, r11 

r11, r9 

rcx, rdx 

QWORD PTR x36$1$[rsp], rax 
r8, rsi 


rdx, rcx 
rdx, r13 
rdx 

rdx, rdi 
r10, rdx 
r10, r9 
r10, rax 
r10, rbx 
rbx 

rbx, r9 
rax, r10 


rax, QWORD PTR al$[rsp] 
rbx, rax 

rax, QWORD PTR out4$[rsp] 
rbx, QWORD PTR [rax] 
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rbx, rcx 

QWORD PTR [rax], rbx 

rbx, QWORD PTR x36$1$[rsp] 
rbx, rbp 

r9, rbx 


r9, rdi 

r8, r11 

rax, QWORD PTR outi$[rsp] 
r8, r9 


r9, rcx 
rdx, rbp 
rbp, QWORD PTR [rsp+80] 
r9, rsi 
rbx, r12 
rcx, r11 


rcx, r9 

r9, rdi 

rbx, r14 

r9, r15 

rcx, rdx 

rdx, QWORD PTR al$[rsp] 


r13, r10 

r9, r11 

rcx, rdx 

r9, rbx 

rbx, QWORD PTR [rsp+72] 
rcx 

rcx, QWORD PTR [rax] 
r9, rdx 


rcx, r8 

QWORD PTR [rax], rcx 
rax, QWORD PTR out3$[rsp] 
r9, r13 

r9, QWORD PTR [rax] 
r9, r8 

QWORD PTR [rax], r9 
r15 

r14 

r13 

r12 
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Le compilateur n'a pas eu besoin d'allouer de l'espace sur la pile. x36 est synonyme 
de a5. 


Il existe cependant des CPUs qui possèdent beaucoup plus de GPR. Itanium possède 
ainsi 128 registres. 


1.37.2 ARM 


Les instructions 64 bits sont apparues avec ARMV8. 


1.37.3 Nombres flottants 


Le traitement des nombres flottants en environnement x86-64 est expliqué ici: 1.38 
on the following page. 


1.37.4 Critiques concernant l'architecture 64 bits 


Certains se sont parfois irrité du doublement de la taille des pointeurs, en particulier 
dans le cache puisque les CPUs x64 ne peuvent de toute maniére adresser que des 
adresses RAM sur 48 bits. 


Les pointeurs ont perdu mes faveurs au point que j'en viens à les 
injurier. Si je cherche vraiment à utiliser au mieux les capacités de mon 
ordinateur 64 bits, j'en conclus que je ferais mieux de ne pas utiliser 
de pointeurs. Les registres de mon ordinateur sont sur 64 bits, mais 
je n'ai que 2Go de RAM. Les pointeurs n'ont donc jamais plus de 32 
bits significatifs. Et pourtant, chaque fois que j'utilise un pointeur, il 
me coúte 64 bits ce qui double la taille de ma structure de données. 
Pire, ils atterrissent dans mon cache et en gaspillent la moitié et cela 
me coúte car le cache est cher. 

Donc, si je cherche à grappiller, j'en viens à utiliser des tableaux 
au lieu de pointeurs. Je rédige des macros compliquées qui peuvent 
laisser l'impression à tort que j'utilise des pointeurs. 


( Donald Knuth dans "Coders at Work: Reflections on the Craft of Programming ". ) 
Certains en sont venus à fabriquer leurs propres allocateurs de mémoire. 


Il est intéressant de se pencher sur le cas de CryptoMiniSat!®*. Ce programme qui 
utilise rarement plus de 4Go de RAM, fait un usage intensif des pointeurs. Il né- 
cessite donc moins de mémoire sur les architectures 32 bits que sur celles à 64 
bits. Pour remédier à ce probléme, l'auteur a donc programmé son propre allocateur 
(dans clauseallocator.(h|cpp)), qui lui permet d'allouer de la mémoire en utilisant 
des identifiants sur 32 bits à la place de pointeurs sur 64 bits. 


18 https: //github.com/msoos/cryptominisat/ 
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1.38 Travailler avec des nombres a virgule flottante 


en utilisant SIMD 


Bien sûr. le FPU est resté dans les processeurs compatible x86 lorsque les extensions 
SIMD ont été ajoutées. 


L'extension SIMD (SSE2) offre un moyen facile de travailler avec des nombres à 
virgule flottante. 


Le format des nombres reste le méme (IEEE 754). 


Donc, les compilateurs modernes (incluant ceux générant pour x86-64) utilisent les 
instructions SIMD au lieu de celles pour FPU. 


On peut dire que c'est une bonne nouvelle, car il est plus facile de travailler avec 
elles. 


Nous allons ré-utiliser les exemples de la section FPU ici: 1.25 on page 285. 


1.38.1 Simple exemple 


#include <stdio.h> 


double f (double a, double b) 


{ 
return a/3.14 + b*4.1; 
}; 
int main() 
{ 
printf ("sfAn", f(1.2, 3.4)); 
}; 
x64 


Listing 1.400 : MSVC 2012 x64 avec optimisation 


__real@4010666666666666 DQ 04010666666666666r  ; 4.1 


__real@40091eb851eb851f DQ 040091eb851eb851fr ; 3.14 
a$ = 8 

b$ = 16 

f PROC 


divsd xmm0, QWORD PTR _ real@40091eb851eb851f 
mulsd xmm1, QWORD PTR __real@4010666666666666 
addsd xmmO, xmml 
ret 0 

f ENDP 


Les valeurs en virgule flottante entrées sont passées dans les registres XMMO-XMM3, 
tout le reste—via la pile 183. 


183MSDN: Parameter Passing 
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a est passé dans XMMO, b—via XMM1. 


Les registres XMM font 128-bit (comme nous le savons depuis la section à propos 
de SIMD : 1.36 on page 525), mais les valeurs double font 64-bit, donc seulement la 
moitié basse du registre est utilisée. 


DIVSD est une instruction SSE qui signifie «Divide Scalar Double-Precision Floating- 
Point Values » (Diviser des nombres flottants double-précision), elle divise une valeur 
de type double par une autre, stockées dans la moitié basse des opérandes. 


Les constantes sont encodées par le compilateur au format IEEE 754. 

MULSD et ADDSD fonctionnent de méme, mais font la multiplication et l'addition. 

Le résultat de l'exécution de la fonction de type double est laissé dans le registre 
XMMO. 


C'est ainsi que travaille MSVC sans optimisation: 


Listing 1.401 : MSVC 2012 x64 


__real@4010666666666666 DQ 04010666666666666r  ; 4.1 


__real@40091eb851eb851f DQ 040091eb851eb851fr ; 3.14 
a$ = 8 

b$ = 16 

f PROC 


movsdx QWORD PTR [rsp+16], xmml 
movsdx QWORD PTR [rsp+8], xmm0 
movsdx xmm0, QWORD PTR a$[rsp] 
divsd xmm0, QWORD PTR  realQ40091eb851eb851f 
movsdx xmm1, QWORD PTR b$[rsp] 
mulsd xmm1, QWORD PTR __real@4010666666666666 
addsd xmmO, xmml 
ret 0 
f ENDP 


Légerement redondant. Les arguments en entrée sont sauvés dans le «shadow space » 
(1.14.2 on page 137), mais seule leur moitié inférieure, i.e., seulement la valeur 64- 
bit de type double. GCC produit le méme code. 


x86 


Compilons cet exemple pour x86. Bien qu'il compile pour x86, MSVC 2012 utilise des 
instructions SSE2: 


Listing 1.402 : MSVC 2012 x86 sans optimisation 


tv70 = -8 ; size = 8 
_a$ = 8 ; size = 8 
b$ = 16 ; size = 8 
f PROC 
push ebp 
mov ebp, esp 
sub esp, 8 
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movsd xmmO, QWORD PTR _a$[ebp] 

divsd xmm0, QWORD PTR  realQ40091eb851eb851f 
movsd xmml, QWORD PTR _b$[ebp] 

mulsd xmm1, QWORD PTR  realQ4010666666666666 
addsd xmmO, xmml 

movsd QWORD PTR tv70[ebp], xmm0 


fld QWORD PTR tv70[ebp] 
mov esp, ebp 
pop ebp 
ret 0 
f ENDP 


Listing 1.403 : MSVC 2012 x86 avec optimisation 


tv67 = 8 ; size = 8 
_a$ = 8 ; size = 8 
_b$ = 16 ; size = 8 
f PROC 


movsd xmml, QWORD PTR _a$[esp-4] 

divsd | xmm1, QWORD PTR  realQ40091eb851eb851f 
movsd xmmO, QWORD PTR _b$[esp-4] 

mulsd xmm0, QWORD PTR  realQ4010666666666666 
addsd xmml, xmm0 

movsd QWORD PTR tv67[esp-4], xmml 


fld QWORD PTR tv67[esp-4] 
ret 0 
f ENDP 


C'est presque le méme code, toutefois, il y a quelques différences relatives aux 
conventions d'appel: 1) les arguments ne sont pas passés dans des registres XMM, 
mais par la pile, comme dans les exemples FPU (1.25 on page 285); 2) le résultat 
de la fonction est renvoyé dans ST(0) — afin de faire cela, il est copié (á travers la 
variable locale tv) depuis un des registres XMM dans ST(0). 
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Essayons l'exemple optimisé dans OllyDbg 


CPU - main thread, module simple 


TIDUSD MI, QUORD PTR S 

DIUSD XMM1,GWORD PTR nm 

MOUSD XMMO, QUORD PTR S AC] 

MULSD Shia, QUORD PTR DS: 18920081 FLOAT 4.1000 x 
F2ØF58C8_ | ADDSD XMM1, “MMA ap 
F20F114024 Ø| MOUSD QUORD PTR SS:LESP*41, XMM1I 901 TFC 
004424 64 |FLD QUORD PTR SS:LESP*41 — 

RETN 2000000 1 
2000008 


61331006 simple.61331006 


ce S 9028 OLFFFFFFFF) 
F20F 1005 cazi nous). "Mo, WORD PTR DS: [13329081 FLOAT 3.4900 |E a DAEEEEEEEET 
83EC 19 SUB E 2 Q(FFFFFFFF) 
FS6F114424 GL MOUSE GWIORD PTR SS: [ESP+87, XMMO ES la 
FSoFIOOS Baal HOUSD RING, GUORD PTR Ds: I 1392068] FLOAT 1.20001 S 9053 CEEDDGORLEE 
F20F118424 | MOUSD QUORD P PTR SS:LESP1, XMMO 2 


EB RDFFFFFF |CALL al LES gbodo " = 
Bosces 08 |FSTP QUORD PTR SS:LESP+81 LastErr 06000000 EHROR-SUCCESS 
00009202 (NO,NB,NE, R, NS, PO, GE, G) 


ADD ESP,8 
PUSH OFFSET 01333000 ASCII "Zzfg" empty 
CALL DWORD PTR DS: C<&MSUCR118.printf21 empty 


—initenv 


ADD ESP, ØC à 
ponents EAX empty 


RETI 
INTS 


empty 
empty 
empty 
5 empty 
? empty 


SODIO 


MOU EAX, SAD goog 

Boo! CHP WORD PTR DS:L«STRUCT IMAGE_DOS_HEADI Fow Ber 
JE SHORT 01331082 a 

ROR EAX, EAX 

JMP SHORT 01321086 

HOU ECX, DWORD PTR DS: [18309301 

CMP DWORD PTR DS:CECK+<STRUCT IMAGE DOS] 

DE SHORT 9130187 


torsscacoles, 1400QDODGQUODEO 
2MM1=0.0, 1. 200000000000900 


nna 1, 200000090090090 
1. Rome 


aaaoiFSa FZ Ø DZ 
Rnd NEAR 


=m 
re 


ws 


RETURN from simple.@1331938 to simple.013 


Pointer to next SEH record 
613 R4 SE handler 


Fig. 1.113: OllyDbg : MOVSD charge la valeur de a dans XMM1 


CPU - main thread, module simple 


01331000 
01331006 


E 
91331614 


8183102E 
B133102F 
91331939 
91331938 
01331038 
01331041 
01331049 
01331004E 
01331053 
01331057 
91331954 
B133105F 
01331065 
01331068 
8133196 
01331068 
60133106C 
01331060 
00133106E 
60133106F 
01331070 
01331075 
91331070 
Bl 07E 
01331080 
01331082 
01331088 
01331092 
3319 


Stack [8l 
AHne-e.a 


A de 
Bl 


1 2060 
01333070 
91333088 
11333090 


F20F104C24 à 
F20FSEOD 
F20F18 


F20F5995 Da 
F20F58C8 
F20F114C24 0 
004424 64 


cc 

F20F1005 Cool 
Foor 114424 © 
F20F1005 Baal 
peor Lorat 


1 7FBCCI=3. 4000000! 
, 1.200000009000008 


! DIUSD XMM1,QUORD PTR 
MOUSD QUORD 


MOUSD XMM1,QWORD PTR S: 


nna. r a que 
MULSD XMMO, QUORD PTR DS: [1332000] 
RDDSD XMM1,XMMO 
MOUSD QUORD_PTR_SS:LESP+4],XMM1 
FED MORD PTR SS: [ESP+4] 


noven ano» QUORD PTR DS: [1332008] 
SUB ESP, 


MOUSD BORD PTR SS: CESP+81, XMMØ 
MOUSD XMMG, WORD PTR DS: [13320B8] 
MOUSD QUORD PTR SS:CESPI,xMMa 
CALL 01331000 

FSTP QUORD PTR SS: [ESP+8] 

ADD ESP,8 

PUSH OFFSET 01333000 

CALL DWORD PTR DS: [<2MSUCR110.printf>] 
ADD ESP, ØC 

XOR EAX, EAX 

RETN 


MOU EAX, SA40 
Gaga! CMP WORD PTR_DS:[<STRUCT IMAGE_DOS_HEADI 
ge SHORT 01331082 


one SHORT 01331086 
MOU ECX, DWORD PTR DS: [1330030] 


CMP DWORD PTR DS: LECX+<STRUCT IMAGE DOS) 


JNE SHORT 60133107E 
MOU EAX, 106 


HE. ung 
ET] 


|FLORT 3.1400 
FLOAT 3.4800 
FLOAT 4.1000 


FLOAT 3.48868 


FLOAT 1.2888 


ASCII "zfg" 


DO17FED4 
@617FBD3 
9617FBDC 
@G17FBEG 
@617FBE4 
DO17FEES 
BB17FBEC 
BO17FEFO 
DO17FEF4 
BO17FEFS 
BO17FBFC 
aaizrFcea 
0017FC04 
BaivcrFCas 


EAX eSF Seed MISUCRL 
ECX 69660538 
EDX 66900090 


I 600009061 
2880608 


60133100E 


empty 
empty 
empty 
empty 
empty 
empty 
5 empty 
empty 


Boga 
027F 
Last cmnd 


simple.8133188E 


32bit B(FFFFFFFF) 
32bit B(FFFFFFFF) 
B2bit B(FFFFFFFF) 
32bit BCFFFFFFFF) 
32bit vEFDDGGerFFF) 
32bit G(FFFFFFFF) 


r 0900099098 ERROR SUCCESS 
2 (NO,NB,NE, R, NS, PO, GE, G) 


1.2800000000000008 
O EO IERRA 


GGGG1FAG F2 Ø DZ G Err 


Rnd NEAR Mask 


(a 
RETURN from simple.01331030 to simple.013 


Pointer to next SEH record 


SE handler 


Fig. 1.114: OllyDbg : DIVSD a calculé le quotient et l'a stocké dans XMM1 


CPU - main thread, module simple 


41331000 


8133196 
01331068 
60133106C 
01331060 
01331106E 
60133106F 
01331070 
01331075 
91331070 


81331082 
91331988 
01331092 


PESENE 
Bl 


1 2060 
01333070 
91333088 
11333090 


5 dL E 


cc 

F20F1005 Cool 
Foor 114424 © 
F20F1005 Baal 
peor Lorat 


ESP+4] 
n RD HE 


9, QUORD PTE | 19920001 —— 
XMM 


CESP+4], XMM1 
FLD QUORD PTR SS: CESP+4] 
RETN 


MOUSD XMM1,QWORD PTR S: 
"m an d En 


noven Ko: QUORD PTR DS: [1332008] 
SUB ESP, 


MOUSD BORD PTR SS: CESP+81, XMMØ 
MOUSD XMMG, WORD PTR DS: [13320B8] 
MOUSD QUORD PTR SS:CESPI,xMMa 
CALL 01331000 

FSTP QUORD PTR SS: [ESP+8] 

ADD ESP,8 

PUSH OFFSET 01333000 

CALL DWORD PTR DS: [<2MSUCR110.printf>] 
ADD ESP, ØC 

XOR EAX, EAX 

RETN 


MOU EAX, SA40 
000 CMP WORD PTR_DS:[<STRUCT IMAGE_DOS_HEADI 
JE SHORT 01331082 


See SHORT 01331086 
MOU ECX, DWORD PTR DS: [1330030] 


CMP DWORD PTR DS: LECX+<STRUCT IMAGE DOS) 


HE EM" Le 


TS, 9400000000000 
8. 2821656050955414 


FLORT 3.1400 
FLORT 4. e 
FLORT 3 


FLOAT 3. 40001 


FLOAT 1.2888 


ASCII "zfg" 


DO17FED4 
@617FBD3 
9617FBDC 
@G17FBEG 
@617FBE4 
DO17FEES 
BB17FBEC 
BO17FEFO 
DO17FEF4 
BO17FEFS 
BO17FBFC 
0017FC00 
0017FC04 
pa17FCOS 


EAX TE MSUCRL 
ECX 66660538 
EDX 66908098 


I 600009061 
2880608 


60133101C 


empty 
empty 
empty 
empty 
empty 
empty 
5 empty 
empty 


Boga 
027F 
Last cmnd 


simple.8133181C 


32bit GtFFFFFFFF) 
32bit G(FFFFFFFF) 
B2bit B(FFFFFFFF) 
32bit BLFFFFFFFF) 
32bit vEFDDeGerFFF) 
32bit G(FFFFFFFF) 


r 0900099098 ERROR SUCCESS 
2 (NO,NB,NE, R, NS, PO, GE, G) 


200000088800 
656850955414 


20000000 


BGGG1FAG FZ Ø DZ Ø Err 


Rnd NEAR Mask 


(a 
RETURN from simple.01331039 to simple.013 


Pointer to next SEH record 


SE handler 


Fig. 1.115: OllyDbg : MULSD a calculé le produit et l'a stocké dans XMMO 


ERX ESF 88634 nRa initeny 


Mö, 
ECX 69660539 
MULSD XMMA, QUORD PTR EDX 0000000B 


BDDSD ri, XMMO 2 
MOUSD GWORD PTR_SS: LESP+41, XMM1 lrEoar-a.a, | EX 20000000 
DEO MORD PTR SS: [ESP+4] 


I 00009061 


INTÉ CETTE] 
INTS 01331020 simple. 01331020 
e RUE ‘ 3 S2bit B(FFFFFFFF) 
F20F 1095 ceal nous xma, , QUORD PTR DS: [1332008] FLOAT 3.4000 |E B Sorte EEE ETE: 
F20F114424 Øi HOUSD QUORD PTR SS:CESP+81, XMNO E cla di 
Fsorloss Beal MOUSD MD, QUORD PTR BS: (1332088) FLOAT 1.20001 E Sebit GIFEEEEFFE) 
EEG ES an UN reer he 
Bosted 0o |FSTP QUORD PTR SS:LESP461 LastErr 00800890 ERROR-SUCCESS 
ADD ESP,8 66006262 (NO,NB,NE,A,NS,PO, GE, G) 
PUSH OFFSET 81333000 ASCII "zB" nU 
CALL DWORD PTR DS: L<&MSUCR118. printf >] FRA 
ADD ESP, ØC ey 
XOR EAK, EAX fror 
RETN empty 

empty 
empty 
empty 


0098 
U EAX, SA4D gore 


MOI 
anal CHP WORD PTR DS: [<STRUCT IMAGE_DOS_HEAD 5 
JE SHORT 01331082 Last omnd 9000; 00000008 
XOR EAX, EAX 
SHORT 91931086 
ECX, DWORD PTR DS:[133003C] 


DWORD PTR DS:CECX+<STRUCT IMAGE DOS| 
E Sere 


nna 13.940G0000000800 


14. locu 
e: . 3 


20000000 


xXMM1=0.0, 14. ATEN 
Stack [OB17FEC4]=1. 200000000000000 


BaaoiFRaO FZ Ø DZ Ø Err 
Rnd NEAR Mask 


0017FBC4 
@617FBC3 
17FBCC 
6617FBD8 
@617FBD4 RETURN from simple.01331039 to simple.013 
@617FBD3 8 
9617FBDC 
Du 
01333080 adici 
HER miren 
BD17FEFO 
GG17FBF4 
GG17FBFS3 
@617FBFC a8 
0017FC00 Pointer to next SEH record 
0017FCO4 . SE handler 
bO17FCOS| 366834F3 


Fig. 1.116: OllyDbg : ADDSD ajoute la valeur dans XMMO à celle dans XMM1 


CPU - main thread, module simple 


F20F104024 87 MOUSD XMMI,QUORD PTR 55: [ESP+4] E 
DIUSD XHMI,QUORD PTR DS: [13320091 FLORT 3.1480 q CRI LOS In itenv 
MOUSD XHMA; QWORD PTR SS: [ESP+8C] ii 
MULSD XHMA, QUORD PTR DS: [13320091 FLOAT 4. 1000 
5 RDDSD XMM1, XMMØ 

F20F114C24 Ø| MOUSD QUDRD PTR SS:CESP+41,XMM1 
DD4g24 G4 [ELO QUORD PTR SS: TESP+41 


> B133102A 
ES à 


cc IN 

F2GF1005 Ce2l MOUSO_XMMG,QWORD PTR DS: [1332008] FLOAT 3.49001 

SSEC 18 SUB ESP, 18 

F20F114424 01 MOUSD GWIORD PTR SS:CESP+81, XMMG ae 

F20F 109e Esel MOUSD AMD, QUORD PTR DS: [15320881 FLOAT 1.20001 EEDE LEE 

F20F110424 -|MOUSD QUORD PTR SS: [ESP], XMMG a 
CALL 81331000 ER 

FSTP QUORD PTR SS: [ESP+8] k 

PUSH OFFSET 01333000 ASCII "Eg" à E 

CALL DORD PTR DS: [<&MSUCR110.printf>] valid 14.90 105609899899999 


IN “€ 

CHP WORD PTR DS: E<STRUCT IMAGE_DOS_HEAD F MESES 
EIP BORD FTR beet nd 8823:81331026 
ROR EAX, EAX 

JMP SHORT 81331086 

MOU ECX, DWORD PTR DS:[133003C1 

CMP DWORD PTR DS:CECK+<STRUCT IMAGE DOS. 
JNE SHORT 90133107E 

MOU EAX, 106 


simple.£ 


RETURN from simple.D01331030 to simple.813 


Pointer to next SEH re 
E handler 


Fig. 1.117: OllyDbg : FLD laisse le résultat de la fonction dans ST(0) 


Nous voyons qu'OllyDbg montre les registres XMM comme des paires de nombres 
double, mais seule la partie basse est utilisée. 


Apparemment, OllyDbg les montre dans ce format car les instructions SSE2 (suf- 
fixées avec -SD) sont exécutées actuellement. 


Mais bien súr, il est possible de changer le format du registre et de voir le contenu 
comme 4 nombres float ou juste comme 16 octets. 
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1.38.2 Passer des nombres a virgule flottante via les argu- 
ments 


#include <math.h> 
#include <stdio.h> 


int main () 
{ 
printf ("32.01 ^ 1.54 = %lf\n", pow (32.01,1.54)); 


return 0; 


} 


Ils sont passés dans la moitié basse des registres XMMQ-XMM3. 


Listing 1.404 : MSVC 2012 x64 avec optimisation 


$SG1354 DB '32.01 ^ 1.54 = %lf', OaH, 00H 
__real@40400147ae147ael DQ 040400147ae147aelr ; 32.01 
. realQ3ff8a3d70a3d70a4 DQ 03ff8a3d70a3d70a4r ; 1.54 
main PROC 
sub rsp, 40 ; 00000028H 
movsdx xmml, QWORD PTR _ real@3ff8a3d70a3d70a4 
movsdx xmmO, QWORD PTR _ real@40400147ae147ael 
call pow 
lea rcx, OFFSET FLAT: $SG1354 
movaps xmml, xmmO 
movd rdx, xmml 
call printf 
xor eax, eax 
add rsp, 40 ; 00000028H 
ret 0 
main ENDP 


Il n'y a pas d'instruction MOVSDX dans les manuels Intel et AMD (12.1.4 on page 1315), 
elle y est appelée MOVSD. Donc il y a deux instructions qui partagent le méme nom 
en x86 (à propos de l'autre lire: .1.6 on page 1334). Apparemment, les développeurs 
de Microsoft voulaient arréter cette pagaille, donc ils l'ont renommée MOVSDX. Elle 
charge simplement une valeur dans la moitié inférieure d'un registre XMM. 


pow() prends ses arguments de XMMO et XMM1, et renvoie le résultat dans XMMO. II est 
ensuite déplacé dans RDX pour printf(). Pourquoi? Peut-étre parce que printf()— 
est une fonction avec un nombre variable d'arguments? 


Listing 1.405 : GCC 4.4.6 x64 avec optimisation 


.LC2: 
.string "32.01 ^ 1.54 = %lf\n" 
main: 
sub rsp, 8 
movsd xmml, QWORD PTR .LCO[ rip] 
movsd xmmO, QWORD PTR .LC1[rip] 
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call pow 
; le résultat est maintenant dans XMMO 
mov edi, OFFSET FLAT:.LC2 
mov eax, 1 ; nombre de registres vecteur passé 
call printf 
xor eax, eax 
add rsp, 8 
ret 
.LC0: 
. Long 171798692 
.long 1073259479 
.LC1: 


.long 2920577761 
.long 1077936455 


GCC génère une sortie plus claire. La valeur pour printf () est passée dans XMMO. À 
propos, il y a un cas lorsque 1 est écrit dans EAX pour printf()—ceci implique qu'un 
argument sera passé dans des registres vectoriels, comme le requiert le standard 
[Michael Matz, Jan Hubicka, Andreas Jaeger, Mark Mitchell, System V Application 
Binary Interface. AMD64 Architecture Processor Supplement, (2013)] 184. 


1.38.3 Exemple de comparaison 


#include <stdio.h> 


double d max (double a, double b) 


1 
if (a>b) 
return a; 
return b; 
}; 
int main() 
{ 
printf ("%f\n", d max (1.2, 3.4)); 
printf ("%f\n", d max (5.6, -4)); 
}; 
x64 
Listing 1.406 : MSVC 2012 x64 avec optimisation 
a$ = 8 
b$ = 16 
d max PROC 
comisd xmmO, xmml 
ja SHORT $LN2QGd max 


l84Aussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64- abi. pdf 
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movaps xmmO, xmml 


$LN2Gd max: 
fatret 0 
d max  ENDP 


MSVC avec optimisation génére un code trés facile à comprendre. 


COMISD is «Compare Scalar Ordered Double-Precision Floating-Point Values and Set 
EFLAGS » (comparer des valeurs double précision en virgule flottante scalaire or- 
drées et mettre les EFLAGS). Pratiquement, c'est ce qu'elle fait. 


MSVC sans optimisation génére plus de code redondant, mais il n'est toujours pas 
trés difficile à comprendre: 


Listing 1.407 : MSVC 2012 x64 


a$ = 8 
b$ = 16 
d_max PROC 
movsdx QWORD PTR [rsp+16], xmm1 
movsdx QWORD PTR [rsp+8], xmm0 
movsdx xmm0, QWORD PTR a$[rsp] 
comisd xmmO, QWORD PTR b$[rsp] 
jbe SHORT $LN1@d_ max 
movsdx xmm0, QWORD PTR a$[rsp] 
jmp SHORT $LN2@d_max 
$LN1@d_max: 
movsdx xmm0, QWORD PTR b$[rsp] 
$LN2@d_max: 
fatret 0 
d max  ENDP 


Toutefois, GCC 4.4.6 effectue plus d'optimisations et utilise l'instruction MAXSD («Re- 
turn Maximum Scalar Double-Precision Floating-Point Value») qui choisit la valeur 
maximum! 


Listing 1.408 : GCC 4.4.6 x64 avec optimisation 


d max: 
maxsd xmmO, xmml 
ret 
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x86 


Compilons cet exemple dans MSVC 2012 avec l'optimisation activée: 


Listing 1.409 : MSVC 2012 x86 avec optimisation 


_a$ = 8 

_b$ = 16 

_d max PROC 
movsd 
comisd 
jbe 
fld 
ret 

$LN1@d_max: 
fld 
ret 

_d max ENDP 


; Size 
; Size 


ol 
00 


xmmO, QWORD PTR _a$[esp-4] 
xmmO, QWORD PTR _b$[esp-4] 
SHORT $LN1QGd max 

QWORD PTR a$[esp-4] 

0 


QWORD PTR b$[esp-4] 
0 


Presque la méme chose, mais les valeurs de a et b sont prises depuis la pile et le 
résultat de la fonction est laissé dans ST(0). 


Si nous chargeons cet exemple dans OllyDbg, nous pouvons voir comment l'instruc- 
tion COMISD compare les valeurs et met/efface les flags CF et PF: 


n thread, module d_max 


3 F20F104424 Ø] MOUSD XMNG,QWORD PTR SS: [ARG. 1] 
+  660F2F4424 BI COMISD XMMO, QWORD PTR SS: [ARG.3] 


«vr76 OS JBE SHORT 98821613 
. [So 04 FLD QWORD PTR SS:CARG.1] 
> 


RETN 
004424 BC FLD QWORD PTR SS: CARG.3] 
c3 RETN 


INT3 
INT: 
INT: 
INT: 
INT: 
INT: 
INT: 


FFFFFFFF) 
D(FFFFFFFF) 
d IT BL FFFFFFFF) 
F20F1995 COZÍ MOUSD_XMMO, QUORD PTR DS: [822000] EL 
S3EC 19 SUB ESP, 18 io dd 
F20F114424 Øi MOUSD WORD PTR SS: [LOCAL. 11, XHMO : 
Feer1ags Baci HOUSD AIME, QUORD PTA DS: ES226881 Lecter 
F20F110424 |MOUSD QWORD PTR SS: LOCAL. 31, «MO = a 
ES BDFFFFFF |CALL 00821000 8888203 (Ní 
DDsC24 88 |FSTP QUORD PTR SS:LLOCRL.11 STO empty 0.0 
ADD ESP,8 ence 0.a 

82308299 |PUSH OFFSET 0822009 BTI eros g.a 
FFAS gaenasai CALL DWORD PTR DSiLCeMSUCRLIO pr int >] HEEL A 
F20F 100 FOUSD »hMO,QORD PTR DS: (822000) erg ente 
F20F114424 Øi MOUSD GWORD PTR SS: [LOCAL. 11, XMMO SIS emery 
Sor 1008 Cal HOUSD XING, GORD PTR DS: 8228000 y 
MOUSD GUORD PTR SS: LOCAL. 31, XMMO ; - 
CALL 98821900 " = DE em 
FSTP_QUORD PTR SS: LOCAL. 1] | : 


ESP, 
PUSH OFFSET 00823004 
CALL DWORD PTR DS: [<8MSUCR11B8.printf>1 
ADD ESP, 0C 
XOR ERX,ERX 
TN 


Jump is taken 
Dest=d_max. 00821013 


RETURN from d_max. 00821020 to d_max.£ 


Fig. 1.118: OllyDbg : COMISD a changé les flags CF et PF 


1.38.4 Calcul de l'epsilon de la machine: x64 et SIMD 


Revoyons l'exemple «calcul de l'epsilon de la machine » pour double listado.1.32.2. 


Maintenant nous compilons pour x64: 


Listing 1.410 : MSVC 2012 x64 avec optimisation 


v$ = 8 

calculate machine epsilon PROC 
movsdx QWORD PTR v$[rsp], xmm0 
movaps xmml, xmmO 
inc QWORD PTR v$[rsp] 
movsdx xmmO, QWORD PTR v$[rsp] 
subsd  xmmO, xmml 
ret 0 

calculate machine epsilon ENDP 


Il n'y a pas moyen d'ajouter 1 à une valeur dans un registre XMM 128-bit, donc il 
doit étre placé en mémoire. 


Il y a toutefois l'instruction ADDSD (Add Scalar Double-Precision Floating-Point Values 
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ajouter des valeurs scalaires à virgule flottante double-précision), qui peut ajouter 
une valeur dans la moitié 64-bit basse d'un registre XMM en ignorant celle du haut, 
mais MSVC 2012 n'est probablement pas encore assez bon !9*. 


Néanmoins, la valeur est ensuite rechargée dans un registre XMM et la soustraction 
est effectuée. SUBSD est «Subtract Scalar Double-Precision Floating-Point Values » 
(soustraire des valeurs en virgule flottante double-précision), i.e., elle opére sur la 
partie 64-bit basse d'un registre XMM 128-bit. Le résultat est renvoyé dans le registre 
XMMO. 


1.38.5 Exemple de générateur de nombre pseudo-aléatoire 
revisité 
Revoyons l'exemple de «générateur de nombre pseudo-aléatoire » listado.1.32.1. 


Si nous compilons ceci en MSVC 2012, il va utiliser les instructions SIMD pour le FPU. 


Listing 1.411 : MSVC 2012 avec optimisation 


. reale3f800000 DD 03f800000r ; 1 


tv128 -4 
_tmp$ = -4 
?float_rand@@YAMXZ PROC 
push ecx 
call ?my_rand@@YAIXZ 
; EAX=valeur pseudo-aléatoire 
and eax, 8388607 ; 007fffffH 
or eax, 1065353216 ; 3f800000H 
EAX-valeur pseudo-aléatoire & 0x007fffff | 0x3f800000 
; la stocker dans la pile locale: 
mov DWORD PTR _tmp$[esp+4], eax 
la recharger comme un nombre a virgule flottante: 
movss  xmm0, DWORD PTR _tmp$[esp+4] 
soustraire 1.0: 
subss  xmm0, DWORD PTR _ real@3f800000 
mettre la valeur dans STO en la placant dans une variable temporaire... 
movss DWORD PTR tv128[esp+4], xmm0 
; =.. et en la rechargeant dans STO: 


fld DWORD PTR tv128[esp+4] 
pop ecx 
ret 0 


?float_rand@@YAMXZ ENDP 


Toutes les instructions ont le suffixe -SS, qui signifie «Scalar Single » (scalaire simple). 
«Scalar» (scalaire) implique qu'une seule valeur est stockée dans le registre. 


«Single » (simple199) signifie un type de donnée float. 


185À titre d'exercice, vous pouvez retravailler ce code pour éliminer l'usage de la pile locale 
186pour simple précision 
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1.38.6 Résumé 


Seule la moitié basse des registres XMM est utilisée dans tous les exemples ici, pour 
stocker un nombre au format IEEE 754. 


Pratiquement, toutes les instructions préfixées par - SD («Scalar Double-Precision »)— 
sont des instructions travaillant avec des nombres à virgule flottante au format IEEE 
754, stockés dans la moitié 64-bit basse d'un registre XMM. 


Et c'est plus facile que dans le FPU, sans doute parce que les extensions SIMD ont 
évolué dans un chemin moins chaotique que celles FPU dans le passé. Le modéle de 
pile de registre n'est pas utilisé. 


Si vous voulez, essayez de remplacer double avec float 


dans ces exemples, la méme instruction sera utilisée, mais préfixée avec -SS («Sca- 
lar Single-Precision » scalaire simple-précision), par exemple, MOVSS, COMISS, ADDSS, 
etc. 


«Scalaire » implique que le registre SIMD contienne seulement une valeur au lieu de 
plusieurs. 


Les instructions travaillant avec plusieurs valeurs dans un registre simultanément 
ont «Packed » dans leur nom. 


Inutile de dire que les instructions SSE2 travaillent avec des nombres 64-bit au for- 
mat IEEE 754 (double), alors que la représentation interne des nombres à virgule 
flottante dans le FPU est sur 80-bit. 


C'est pourquoi la FPU produit moins d'erreur d'arrondi et par conséquent, le FPU 
peut donner des résultats de calcul plus précis. 


1.39 Détails spécifiques à ARM 


1.39.1 Signe (+) avant un nombre 


Le compilateur Keil, IDA et objdump font précéder tous les nombres avec le signe 
« 4 », par exemple: listado.1.22.1. 


Mais lorsque GCC 4.9 génére une sortie en langage d'assemblage, il ne le fait pas, 
par exemple: listado.3.18. 


Les listings ARM dans ce livre sont quelque peu mélangés. 


Il est difficile de dire quelle méthode est juste. On est supposé suivre les régles 
admises de l'environnement dans lequel on travaille. 


1.39.2 Modes d'adressage 


Cette instruction est possible en ARM64: 


ldr x0, [x29,24] 
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Ceci signifie ajouter 24 à la valeur dans X29 et charger la valeur à cette adresse. 


Notez s'il vous plait que 24 est à l'intérieur des parenthéses. La signification est 
différente si le nombre est à l'extérieur des parenthéses: 


ldr w4, [x1],28 


Ceci signifie charger la valeur à l'adresse dans X1, puis ajouter 28 à X1. 


ARM permet d'ajouter ou de soustraire une constante à/de l'adresse utilisée pour 
charger. 


Et il est possible de faire cela à la fois avant et aprés le chargement. 


Il n'y a pas de tels modes d'adressage en x86, mais ils sont présents dans d'autres 
processeurs, méme sur le PDP-11. 


Il y a une légende disant que les modes pré-incrémentation, post-incrémentation, 
pré-décrémentation et post-décrémentation du PDP-11, sont «responsables » de l'ap- 
parition du genre de constructions en langage C (qui a été développé sur PDP-11) 
comme *ptr- c, *++ptr, *ptr--, *--ptr. 


À propos, ce sont des caractéristiques de C difficiles à mémoriser. Voici comment ca 
se passe: 


terme C terme ARM déclaration C | ce que ca fait 


Post-incrémentation | adressage post-indexé | *ptr++ utiliser la valeur *ptr, 
puis incrémenter 
le pointeur ptr 


Post-décrémentation | adressage post-indexé | *ptr-- utiliser la valeur *ptr, 
puis décrémenter 
le pointeur ptr 


Pré-incrémentation adressage pré-indexé *++ptr incrémenter le pointeur ptr, 
puis utiliser 
la valeur *ptr 
Pré-décrémentation | adressage pré-indexé | *--ptr décrémenter le pointeur ptr, 
puis utiliser 


la valeur *ptr 


La pré-indexation est marquée avec un point d'exclamation en langage d'assem- 
blage ARM. Par exemple, voir ligne 2 dans listado.1.28. 


Dennis Ritchie (un des créateurs du langage C) a mentionné que cela a vraisembla- 
blement été inventé par Ken Thompson (un autre créateur du C) car cette possibilité 
était présente sur le PDP-7 187, [Dennis M. Ritchie, The development of the C lan- 
guage, (1993)]*88. 


Ainsi, les compilateurs de langage C peuvent l'utiliser, si elle est présente sur le 
processeur cible. 


C'est trés pratique pour le traitement de tableau. 


187http://yurichev.com/mirrors/C/c dmr postincrement.txt 
188 Aussi disponible en pdf 
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1.39.3 Charger une constante dans un registre 
ARM 32-bit 


Comme nous le savons déja, toutes les instructions ont une taille de 4 octets en 
mode ARM et de 2 octets en mode Thumb. 


Mais comment peut-on charger une valeur 32-bit dans un registre, s'il n'est pas 
possible de l'encoder dans une instruction? 


Essayons: 
unsigned int f() 
1 

return 0x12345678; 
I 

Listing 1.412 : GCC 4.6.3 -O3 Mode ARM 

f: 

ldr ro, .L2 

bx lr 
.L2: 


.word 305419896 ; 0x12345678 


Donc, la valeur 0x12345678 est simplement stockée à part en mémoire et chargée 
si besoin. 


Mais il est possible de se débarrasser de l'accés supplémentaire en mémoire. 


Listing 1.413 : GCC 4.6.3 -03 -march=armv7-a (Mode ARM) 


movw ro, #22136 ; 0x5678 
movt rO, #4660 ; 0x1234 
bx lr 


Nous voyons que la valeur est chargée dans le registre par parties, la partie basse 
en premier (en utilisant MOVW), puis la partie haute (en utilisant MOVT). 


Ceci implique que 2 instructions sont nécessaires en mode ARM pour charger une 
valeur 32-bit dans un registre. 


Ce n'est pas un probléme, car en fait il n'y pas beaucoup de constantes dans du 
code réel (excepté pour 0 et 1). 


Est-ce que ca signifie que la version à deux instructions est plus lente que celle à 
une instruction? 


C'est discutable. Le plus souvent, les processeurs ARM modernes sont capable de 
détecter de telle séquences et les exécutent rapidement. 


D'un autre cóté, IDA est capable de détecter ce genre de patterns dans le code et 
désassemble cette fonction comme: 


MOV RO, 0x12345678 
BX LR 
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ARM64 


uint64 t f() 
1 


}; 


return 0x12345678ABCDEF01; 


Listing 1.414 : GCC 4.9.1 -03 


mov x0, 61185 ; Oxef01 
movk x0, Oxabcd, 1sl 16 
movk x0, 0x5678, lsl 32 
movk x0, 0x1234, lsl 48 
ret 


MOVK signifie «MOV Keep » (déplacer garder), i.e., elle écrit une valeur 16-bit dans 
le registre, sans affecter le reste des bits. Le suffixe LSL signifie décaler la valeur à 
gauche de 16, 32 et 48 bits à chaque étape. Le décalage est fait avant le chargement. 


Ceci implique que 4 instructions sont nécessaires pour charger une valeur de 64-bit 
dans un registre. 


Charger un nombre à virgule flottante dans un registre 
Il est possible de stocker un nombre à virgule flottante dans un D-registre en utilisant 


une seule instruction. 


Par exemple: 


double a() 
1 

return 1.5; 
}; 


Listing 1.415 : GCC 4.9.1 -03 + objdump 


0000000000000000 <a>: 
0: 1e6f1000 fmov dO, #1.500000000000000000e+000 
4: d65f03c0 ret 


Le nombre 1.5 a en effet été encodé dans une instruction 32-bit. Mais comment? 


En ARM64, il y a 8 bits dans l'instruction FMOV pour encoder certains nombres à 
virgule flottante. 


L'algorithme est appelé VFPExpandImm() en [ARM Architecture Reference Manual, 
ARMv8, for ARMv8-A architecture profile, (2013)]19?. Ceci est aussi appelé mini- 
float1% (mini flottant). 


189Aussi disponible en http://yurichev.com/mirrors/ARMv8-A Architecture Reference Manual _ 
(Issue A.a).pdf 
190wikipédia 
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Nous pouvons essayer différentes valeurs. Le compilateur est capable d'encoder 30.0 
et 31.0, mais il ne peut pas encoder 32.0, car 8 octets doivent étre alloués pour ce 
nombre au format IEEE 754: 


double a() 
1 

return 32; 
}; 

Listing 1.416 : GCC 4.9.1 -03 

a: 

ldr dO, .LCO 

ret 
.LC0: 

.word 0 


.word 1077936128 


1.39.4 Relogement en ARM64 


Comme nous le savons, il y a des instructions 4-octet en ARM64, donc il est impos- 
sible d'écrire un nombre large dans un registre en utilisant une seule instruction. 


Cependant, une image exécutable peut étre chargée à n'importe quelle adresse 
aléatoire en mémoire, c'est pourquoi les relogements existent. 


L'adresse est formée en utilisant la paire d'instructions ADRP et ADD en ARM64. 


La premiére charge l'adresse d'une page de 4KiB et la seconde ajoute le reste. Com- 
pilons l'exemple de «Hello, world! » (listado.1.11) avec GCC (Linaro) 4.9 sous win32: 


Listing 1.417 : GCC (Linaro) 4.9 et objdump du fichier objet 


..»aarch64-linux-gnu-gcc.exe hw.c -C 


..»aarch64-linux-gnu-objdump.exe -d hw.o 


0000000000000000 <main>: 


0: a9bf7bfd stp x29, x30, [sp,£-16]! 
4: 910003fd mov x29, sp 

8: 90000000 adrp x0, 0 «main» 

C: 91000000 add x0, x0, #0x0 

10: 94000000 bl 0 <printf> 

14: 52800000 mov wO, #0x0 // #0 

18: a8c17bfd ldp x29, x30, [sp],#16 
1c: d65f03c0 ret 


..»aarch64-linux-gnu-objdump.exe -r hw.o 


RELOCATION RECORDS FOR [.text]: 
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OFFSET TYPE VALUE 
0000000000000008 R AARCH64 ADR PREL PG HI21 .rodata 
000000000000000c R AARCH64 ADD ABS LO12 NC .rodata 
0000000000000010 R AARCH64 CALL26 printf 


Donc, il y a 3 relogements dans ce fichier objet. 


* La première prend l'adresse de la page, coupe les 12 bits du bas et écrit les 
21 bits du haut restants dans le champs de bit de l'instruction ADRP. Ceci car 
nous n'avons pas besoin d'encoder les 12 bits bas, et l'instruction ADRP possède 
seulement de l'espace pour 21 bits. 


La seconde met les 12 bits de l'adresse relative au début de la page dans le 
champ de bits de l'instruction ADD. 


La derniére, celle de 26-bit, est appliquée à l'instruction à l'adresse 0x10 oü le 
saut à la fonction printf() se trouve. 


Toutes les adresses des instructions ARM64 (et ARM en mode ARM) ont zéro 
dans les deux bits les plus bas (car toutes les instructions ont une taille de 4 oc- 
tets), donc on doit seulement encoder les 26 bits du haut de l'espace d'adresse 
de 28-bit (+128MB). 


Il n'y a pas de tels relogements dans le fichier exécutable: car l'adresse où se trouve 
la chaine «Hello! » est connue, la page, et l'adresse de puts() sont aussi connues. 


Donc, il y a déjà des valeurs mises dans les instructions ADRP, ADD et BL (l'éditeur de 
liens à écrit des valeurs lors de l'édition de liens) : 


Listing 1.418 : objdump du fichier exécutable 


0000000000400590 <main>: 


400590: a9bf7bfd stp x29, x30, [sp,£-16]! 
400594: 910003fd mov x29, sp 

400598: 90000000 adrp x0, 400000 < init-0x3b8» 
40059c: 91192000 add x0, x0, #0x648 

4005a0: 97ffffa0 bl 400420 <puts@plt> 
4005a4: 52800000 mov wO, #0x0 // #0 

4005a8: a8c17bfd ldp x29, x30, [sp],#16 
4005ac: d65f03c0 ret 


Contents of section .rodata: 
400640 01000200 00000000 48656c6c 6f210000 ........ Hello!.. 


À titre d'exemple, essayons de désassembler manuellement l'instruction BL. 
0x97ffffa0 est 0b10010111111111111111111110100000. D'après [ARM Architecture Refe- 
rence Manual, ARMv8, for ARMv8-A architecture profile, (2013)C5.6.26], imm26 cor- 
respond aux derniers 26 bits: 

imm26 = 0b11111111111111111110100000. II s'agit de Ox3FFFFAO, mais le MSB est 1, donc 
le nombre est négatif, et nous pouvons le convertir manuellement en une forme pra- 
tique pour nous. D'après les règles de la négation, il faut simplement inverser tous 
les bits (ca donne 0b1011111=0x5F), et ajouter 1 (0x5F+1=0x60). Donc le nombre 
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sous sa forme signée est -0x60. Multiplions -0x60 par 4 (car l'adresse est stockée 
dans l'opcode est divisée par 4) : ca fait -0x180. Maintenant calculons l'adresse de 
destination: 0x4005a0 + (-0x180) = 0x400420 (noter s'il vous plait: nous considérons 
l'adresse de l'instruction BL, pas la valeur courante du PC, qui peut étre différente!). 
Donc l'adresse de destination est 0x400420. 


Plus d'informations relatives aux relogements en ARM64: [ELF for the ARM 64-bit 
Architecture (AArch64), (2013)]??!. 


1.40 Détails spécifiques MIPS 


1.40.1 Charger une constante 32-bit dans un registre 


unsigned int f() 


1 
}; 


return 0x12345678; 


Toutes les instructions MIPS, tout comme en ARM, ont une taille de 32-bit, donc il 
n'est pas possible d'inclure une constante 32-bit dans une instruction. 


Donc il faut utiliser au moins deux instructions: la premiére charge la partie haute 
du nombre de 32-bit et la seconde effectue une opération OR, qui met effectivement 
la partie 16-bit basse du registre de destination: 


Listing 1.419 : GCC 4.4.5 -O3 (résultat en sortie de l'assembleur) 


li $2,305397760 # 0x12340000 
j $31 
ori $2,$2,0x5678 ; slot de délai de branchement 


IDA reconnaît ce pattern de code, qui se rencontre fréquemment, donc, par commo- 
dité, il montre la derniére instruction ORI comme la pseudo-instruction LI qui charge 
soit disant un nombre entier de 32-bit dans le registre $VO. 


Listing 1.420 : GCC 4.4.5 -O3 (IDA) 


lui $v0, 0x1234 
jr $ra 
li $v0, 0x12345678 ; slot de délai de branchement 


La sortie de l'assembleur GCC a la pseudo instruction LI, mais il s'agit en fait ici de 
LUI («Load Upper Immediate » charger la valeur immédiate en partie haute), qui 
stocke une valeur 16-bit dans la partie haute du registre. 


Regardons la sortie de objdump : 


Listing 1.421 : objdump 


00000000 <f>: 


19 Aussi disponible en http: //infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B __ 
aaelf64.pdf 
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0: 3c021234 lui v0,0x1234 
4: 03e00008 jr ra 
8: 34425678 ori v0,v0,0x5678 


Charger une variable globale 32-bit dans un registre 


unsigned int global var-0x12345678; 


unsigned int f2() 
1 


}; 


return global var; 


Ceci est légèrement différent: LUI charge les 16-bit haut de global var dans $2 (ou 
$VO) et ensuite LW charge les 16-bit bas en l'ajoutant au contenu de $2: 


Listing 1.422 : GCC 4.4.5 -O3 (résultat en sortie de l'assembleur) 


f2: 

lui $2,%hi(global var) 

lw $2, %lo(global_var) ($2) 

j $31 

nop ; slot de délai de branchement 
global var: 


.word 305419896 


IDA reconnaît cette paire d'instructions fréquemment utilisée, donc il concaténe en 
une seule instruction LW. 


Listing 1.423 : GCC 4.4.5 -O3 (IDA) 


_f2: 
lw $v0, global var 
jr $ra 
or $at, $zero ; slot de délai de branchement 
.data 
.globl global var 
global var: .word 0x12345678 # DATA XREF: f2 


La sortie d’objdump est la méme que la sortie assembleur de GCC: Affichons le code 
de relogement du fichier objet: 


Listing 1.424 : objdump 


objdump -D filename.o 
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0000000c <f2>: 


C: 3c020000 lui v0,0x0 

10: 8c420000 lw v0,0(v0) 

14: 03e00008 jr ra 

18: 00200825 move at,at ; slot de délai de branchement 
1c: 00200825 move at,at 


Désassemblage de la section .data: 


00000000 <global_var>: 
0: 12345678 beq s1,54,159e4 <f2+0x159d8> 


objdump -r filename.o 


RELOCATION RECORDS FOR [.text]: 


OFFSET TYPE VALUE 
0000000c R MIPS HI16 global_var 
00000010 R MIPS LO16 global_var 


Nous voyons que l'adresse de global var est écrite dans les instructions LUI et LW 
lors du chargement de l'exécutable: la partie haute de global var se trouve dans la 
première (LUI), la partie basse dans la seconde (LW). 


1.40.2 Autres lectures sur les MIPS 
Dominic Sweetman, See MIPS Run, Second Edition, (2010). 


Chapitre 2 


Fondamentaux importants 


2.1 Types intégraux 


Un type intégral est un type de données dont les valeurs peuvent étre converties 
en nombres. Les types intégraux comportent les nombres, les énumérations et les 
booléens. 


2.1.1 Bit 


Les valeurs booléennes sont une utilisation évidente des bits: O pour faux et 1 pour 
vrai. 


Plusieurs valeurs booléennes peuvent étre regroupées en un mot : Un mot de 32 bits 
contiendra 32 valeur booléennes, etc. On appelle bitmap ou bitfield un tel assem- 
blage. 


Cette approche engendre un surcoüt de traitement: décalages, extraction, etc. A 
l'inverse l'utilisation d'un mot (ou d'un type int) pour chaque booléen gaspille de 
l'espace, au profit des performances. 


Dans les environnements C/C++, la valeur O représente faux et toutes les autres 
valeurs vrai. Par exemple: 


if (1234) 

printf ("toujours exécuté\n"); 
else 

printf ("jamais exécuté An"); 


Une maniére courante d'énumérer les caractéres d'une chaine en langage C: 


char *input=...; 


while(*input) // exécute le corps si le caractére *input est 
EIS iii de zéro 


// utiliser *input 


577 


578 


input++; 
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2.1.2 Nibble 
AKA demi-octet, tétrade. Représente 4 bits. 


Toutes ces expressions sont toujours en usage. 


Binary-Coded decimal (BCD!) 


Les demi-octets ont été utilisés par des CPU 4-bits tel que le Intel 4004 (utilisé dans 
les calculatrices). 


On notera que la représentation binary-coded decimal (BCD) a été utilisée pour repré- 
senter les nombres sur 4 bits. L'entier O est représenté par la valeur 0b0000, l'entier 
9 par 0b1001 tandis que les valeurs supérieures ne sont pas utilisées. La valeur déci- 
male 1234 est ainsi représentée par 0x1234. Il est évident que cette représentation 
n'est pas la plus efficace en matiére d'espace. 


Elle posséde en revanche un avantage: la conversion des nombres depuis et vers 
le format BCD est extrémement simple. Les nombres au format BCD peuvent étre 
additionnés, soustraits, etc., au prix d'une opération supplémentaire de gestion des 
demi-retenues. Les CPUs x86 proposent pour cela quelques instructions assez rares: 
AAA/DAA (gestion de la demi-retenue aprés addition), AAS/DAS (gestion de la demi- 
retenue aprés soustraction), AAM (aprés multiplication), AAD (aprés division). 


Le support parles CPUs des nombres au format BCD est la raison d'étre des half-carry 
flag (sur 8080/Z80) et auxiliary flag (AF sur x86). Ils représentent la retenue générée 
aprés traitement des 4 bits de poids faible (d'un octet). Le drapeau est utilisé par 
les instructions de gestion de retenue ci-dessus. 


Le livre [Peter Abel, /BM PC assembly language and programming (1987)] doit sa 
popularité à la facilité de ces conversions. Hormis ce livre, l'auteur de ces notes n'a 
jamais rencontré en pratique de nombres au format BCD, sauf dans certains nombres 
magiques (5.6.1 on page 925), tels que lorsque la date de naissance d'un individu 
est encodé sous la forme 0x19791011—qui n'est autre qu'un nombre au format BCD. 


Étonnement, j'ai trouvé que des nombres encodés BCD sont utilisés dans le logiciel 
SAP: https://yurichev.com/blog/SAP/. Certains nombres, prix inclus, sont enco- 
dés en format BCD dans la base de données. Peut-étre ont-ils utilisé ce format pour 
étre compatible avec d'anciens logiciels ou matériel? 


Les instructions x86 destinées au traitement des nombres BCD ont parfois été utili- 
sées à d'autres fins, le plus souvent non documentées, par exemple: 


cmp al, 10 
sbb al,69h 
das 
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Ce fragment de code abscons converties les nombres de 0 à 15 en caratères ASCII 
MO AF, 


Z80 


Le processeur Z80 était un clone de la CPU 8 bits 8080 d'Intel. Par manque de place, 
il utilisait une UAL de 4 bits. Chaque opération impliquant deux nombres de 8 bits 
devait étre traitée en deux étapes. Il en a découlé une utilisation naturelle des half- 
carry flag. 


2.1.3 Caractére 


A l'heure actuelle, l'utilisation de 8 bits par caractère est pratique courante. Il n'en a 
pas toujours été ainsi. Les cartes perforées utilisées pour les télétypes ne pouvaient 
comporter que 5 ou 6 perforations par caractéres, et donc autant de bits. 


Le terme octet met l'accent sur l'utilisation de 8 bits.: fetchmail est un de ceux qui 
utilise cette terminologie. 


Sur les architectures à 36 bits, l'utilisation de 9 bits par caractére a été utilisée: un 
mot pouvait contenir 4 caracteres. Ceci explique peut-étre que le standard C/C++ 
indique que le type char doit supporter au moins 8 bits, mais que l'utilisation d'un 
nombre plus importants de bits est autorisé. 


Par exemple, dans l'un des premiers ouvrage sur le langage C ?, nous trouvons : 


char one byte character (PDP-11, IBM360: 8 bits; H6070: 9 bits) 


H6070 signifie probablement Honeywell 6070, qui comprenait des mots de 36 bits. 


table ASCII standard 


La représentation ASCII des caractéres sur 7 bits constitue un standard, qui sup- 
porte donc 128 caractéres différents. Les premiers logiciels de transport de mails 
fonctionnaient avec des codes ASCII sur 7 bits. Le standard MIME? nécessitait donc 
l'encodage des messages rédigés avec des alphabets non latins. Le code ASCII sur 
7 bits a ensuite été augmenté d'un bit de parité qui a aboutit à la représentation sur 
8 bits. 


Les clefs de chiffrage utilisées par Data Encryption Standard (DES^) comportent 56 
bits, soit 8 groupes de 7 bits ce qui laisse un espace pour un bit de parité dans 
chaque groupe. 


La mémorisation de la table ASCII est inutile. Il suffit de se souvenir de certains in- 
tervalles. [0..0x1F] sont les caractéres de contróle (non imprimables). [0x20..0x7E] 


?https://yurichev.com/mirrors/C/bwk- tutor.html 
3Multipurpose Internet Mail Extensions 
^Data Encryption Standard 
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sont les caractères imprimables. Les codes à partir de la valeur 0x80 sont géné- 
ralement utilisés pour les caractéres non latins et pour certains caractéres pseudo 
graphiques. 


Quelques valeurs typiques à mémoriser sont : 0 (terminateur d'une chaine de carac- 
tères en C, '\0' et C/C++); OxA ou 10 (fin de ligne, 'Nn' en C/C++); OxD ou 13 
(retour chariot, 'Nr' en C/C++). 


0x20 (espace). 


CPUs 8 bits 


Les processeurs x86 - descendants des CPUs 8080 8 bits - supportent la manipu- 
lation d'octet(s) au sein des registres. Les CPUs d'architecture RISC telles que les 
processeurs ARM et MIPS n'offrent pas cette possibilité. 


2.1.4 Alphabet élargi 


Il s'agit d'une tentative de supporter des langues non européennes en étendant le 
stockage d'un caractére à 16 bits. L'exemple le plus connu en est le noyau Windows 
NT et les fonctions win32 suffixées d'un W. Cet encodage est nommé UCS-2 ou UTF- 
16. Son utilisation explique la présence d'octets à zéro entre chaque caractére d'un 
texte en anglais ne comportant que des caractéres latins. 


En régle général, la notation wchar t est un synonyme du type short qui utilise 16 
bits. 


2.1.5 Entier signé ou non signé 


Certains s'étonneront qu'il existe un type de données entier non signé (positif ou nul) 
puisque chaque entier de ce type peut étre représenté par un entier signé (positif 
ou négatif). Certes, mais le fait de ne pas avoir à utiliser un bit pour représenter 
le signe permet de doubler la taille de l'intervalle des valeurs qu'il est possible de 
représenter. Ainsi un octet signé permet de représenter les valeurs de -128 à +127, 
et l'octet non signé les valeurs de 0 à 255. Un autre avantage d'utiliser un type de 
données non signé est l'auto-documentation: vous définissez une variable qui ne 
peut pas recevoir de valeurs négatives. 


L'absence de type de données non signées dans le langage Java a été critiqué. L'im- 
plémentation d'algorithmes cryptographiques à base d'opérations booléennes avec 
les seuls types de données signées est compliquée. 


Une valeur telle que OxFFFFFFFF (-1) est souvent utilisée, en particulier pour repré- 
senter un code d'erreur. 


2.1.6 Mot 


mot Le terme de 'mot' est quelque peu ambigu et dénote en général un type de 
données dont la taille correspond à celle d'un GPR. L'utilisation d'octets est pratique 
pour le stockage des caractéres, mais souvent inadapté aux calculs arithmétiques. 
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C'est pourquoi, nombre de CPUs possédent des GPRs dont la taille est de 16, 32 ou 
64 bits. Les CPUs 8 bits tels que le 8080 et le Z80 proposent quant à eux de travailler 
sur des paires de registres 8 bits, dont chacune constitue un pseudo-registre de 16 
bits. (BC, DE, HL, etc.). Les capacités des paires de registres du Z80 en font, en 
quelque sorte, un émulateur d'une CPU 16 bits. 


En régle générale, un CPU présenté comme "CPU n-bits" posséde des GPRs dont la 
taille est de n bits. 


À une certaine époque, les disques durs et les barettes de RAM étaient caractérisés 
comme ayant n kilo-mots et non pas b kilooctets/megaoctets. 


Par exemple, Apollo Guidance Computer posséde 2048 mots de RAM. S'agissant d'un 
ordinateur 16 bits, il y avait donc 4096 octets de RAM. 


La mémoire magnétique du 7X-0 était de 64K mots de 18 bits, i.e., 64 kilo-mots. 


DECSYSTEM-2060 pouvait supporter jusqu'à 4096 kilo mots de solid state memory 
(i.e., hard disks, tapes, etc). S'agissant d'un ordinateur 36 bits, cela représentait 
18432 kilo octets ou 18 mega octets. 


En fait, pourquoi auriez-vous besoin d'octets si vous avez des mots? Surtout pour le 
traitement des chaînes de texte. Les mots peuvent être utilisés dans presque toutes 
les autres situations. 


int en C/C++ est presque systématiquement représenté par un mot. (L'architecture 
AMD64 fait exception car le type int possède une taille de 32 bits, peut-être pour 
une meilleure portabilité.) 


Le type int est représenté sur 16 bits par le PDP-11 et les anciens compilateurs MS- 
DOS. Le type int est représenté sur 32 bits sur VAX, ainsi que sur l'architecture x86 
à partir du 80386, etc. 


De plus, dans les programmes C/C++, le type int est utilisé par défaut lorsque le 
type d'une variable n'est pas explicitement déclaré. Cette pratique peut apparaitre 
comme un héritage du langage de programmation B?. 


L'accés le plus rapide à une variable s'effectue lorsqu'elle est contenue dans un 
GPR, plus méme qu'un ensemble de bits, et parfois méme plus rapide qu'un octet 
(puisqu'il n'est pas besoin d'isoler un bit ou un octet au sein d'un GPR). Ceci reste 
vrai méme lorsque le registre est utilisé comme compteur d'itération d'une boucle 
de 0 à 99. 


En langage assembleur x86, un mot représente 16 bits, car il en était ainsi sur les 
processeurs 8086 16 bits. Un Double word représente 32 bits, et un quad word 64 
bits. C'est pourquoi, les mots de 16 bits sont déclarés par DW en assembleur x86, 
ceux de 32 bits par DD et ceux de 64 bits par DQ. 


5http://yurichev.com/blog/typeless/ 
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Dans les architectures ARM, MIPS, etc... un mot représente 32 bits, on parlera alors 
de demi-mot pour les types sur 16 bits. En conséquence, un double word sur une 
architecture RISC 32 bits est un type de données qui représente 64 bits. 


GDB utilise la terminologie suivante : demi-mot pour 16 bits, mot pour 32 bits et mot 
géant pour 64 bits. 


Les environnements C/C++ 16 bits sur PDP-11 et MS-DOS définissent le type long 
comme ayant une taille de 32 bits, ce qui serait sans doute une abréviation de long 
word ou de long int. 


Les environnements C/C++ 32 bits définissent le type long long dont la taille est de 
64 bits. 


L'ambiguité du terme mot est donc désormais évidente. 


Dois-je utiliser le type int? 


Certains affirment que le type int ne doit jamais étre utilisé, l'ambiguité de sa défini- 
tion pouvant étre génératrice de bugs. A une certaine époque, la bibliothéque bien 
connue /zhuf utilisais le type int et fonctionnait parfaitement sur les architectures 
16 bits. Portée sur une architecture pour laquelle le type int représentait 32 bits, elle 
pouvait alors crasher: http://yurichev.com/blog/lzhuf/. 


Des types de données moins ambigus sont définis dans le fichier stdint.h : uint8 t, 
uint16 t, uint32 t, uint64 t, etc. 


Donald E. Knuth fut l'un de ceux qui proposa d'utiliser pour ces différents types des 
dénominations aux consonances distinctes: octet/wyde/tetrabyte/octabyte. Cette 
pratique est cependant moins courante que celle consistant à inclure directement 
dans le nom du type les termes u (unsigned) ainsi que le nombre de bits. 


Ordinateurs à base de mots 


En dépit de l'ambiguité du terme mot, les ordinateurs modernes restent concus sur 
ce concept: la RAM ainsi que tous les niveaux de mémoire cache demeurent or- 
ganisés en mots et non pas en octets. La notion d'octet reste prépondérante en 
marketing. 


Les accés aux adresses mémoire et cache alignées sur des frontiéres de mots est 
souvent plus performante que lorsque l'adresse n'est pas alignée. 


Afin de rendre performante l'utilisation des structures de données, il convient tou- 
jours de de prendre en compte la longueur du mot du CPU sur lequel sera exécuté 
le programme lors de la définition des structures de données. Certains compilateurs 
- mais pas tous - prennent en charge cet alignement. 


2.1.7 Registre d'adresse 


Ceux qui ont fait leur premiéres armes sur les processeurs x86 32 et 64 bits, ou 
les processeurs RISC des années 90 tels que ARM, MIPS ou PowerPC prennent pour 


Shttp://ww-cs- faculty.stanford.edu/-uno/news98.html 
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acquis que la taille du bus d'adresse est la méme que celle d'un GPR ou d'un mot. 
Cependant, cette régle n'est pas toujours respectée sur d'autres architectures. 


Le processeur 8 bits Z80 peut adresser 2!6 octets, en utilisant une paire de registres 8 
bits ou certains registres spécialisés (IX, IY). En outre sur ce processeur les registres 
SP et PC contiennent 16 bits. 


Le super calculateur Cray-1 possedent des registres généraux de 64-bit, et des re- 
gistres d'adressage de 24 bits. Il peut donc adresser 2?! octets, soit (16 mega mots 
ou 128 mega octets). La RAM coútait trés cher, et un Cray typique avait 1048576 
(0x100000) mots de RAM, soit 8MB. Dans les années 70, la RAM était trés coüteuse. 
Il paraissait alors inconcevable qu'un tel calculateur atteigne les 128 Mo. Des lors 
pourquoi aurait-on utilisé des registres 64 bits pour l'adressage? 


Les processeurs 8086/8088 utilisent un schéma d'adressage particuliérement bi- 
zarre: Les valeurs de deux registres de 16 bits sont additionnées de maniére étrange 
afin d'obtenir une adresse sur 20 bits. S'agirait-il d'une sorte de virtualisation gad- 
get (11.7 on page 1297)? Les processeurs 8086 pouvaient en effet faire fonctionner 
plusieurs programmes cóte à cóte (mais pas simultanément bien súr). 


Les premiers processeurs ARM1 implémentent un artefact intéressant: 


Un autre point intéressant est l'absence de quelques bits dans le 
registre PC. Le processeur ARM1 utilisant des adresses sur 26 bits, les 
6 bits de poids fort ne sont pas utilisés. Comme toutes les adresses 
sont alignées sur une frontiére de 32 bits, les deux bits les moins si- 
gnificatifs du registre PC sont toujours égaux à 0. Ces 8 bits sont non 
seulement inutilisés mais purement et simplement absents du proces- 
seur. 


(http://www.righto.com/2015/12/reverse-engineering-arml-ancestor-of.html 


) 


En conséquence, il n'est pas possible d'affecter au registre PC une valeur dont l'un 
des deux bits de poids faible est différent de 0, pas plus qu'il n'est possible de posi- 
tionner à 1 l'un des 6 bits de poids fort. 


L'architecture x86-64 utilise des pointeurs et des adresses sur 64 bits, cependant en 
interne la largeur du bus d'adresse est de 48 bits, (ce qui est suffisant pour adresser 
256 Tera octets de RAM). 


2.1.8 Nombres 
A quoi sont utilisés les nombres ? 


Lorsque vous constatez que la valeur d'un registre de la CPU est modifié selon un 
certain motif, vous pouvez chercher à comprendre à quoi correspond ce motif. La ca- 
pacité à déterminer le type de données qui découle de ce motif est une compétence 
précieuse pour le reverse engineer . 
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Booléen 


Si le nombre alterne entre les valeurs O et 1, il y a des chances importantes pour 
qu'il s'agisse d'une valeur booléenne. 


Compteur de boucle, index dans un tableau 


Une variable dont la valeur augmente régulièrement en partant de 0, tel que 0, 1, 2, 
3...— est probablement un compteur de boucle et/ou un index dans un tableau. 


Nombres signés 


Si vous constatez qu'une variable contient parfois des nombres trés petits et d'autre 
fois des nombres trés grands, tels que 0, 1, 2, 3, et OXFFFFFFFF, OxFFFFFFFE, OxFFFFFFFD, 
il est probable qu'il s'agisse d'un entier signé sous forme de two's complement au- 
quel cas les 3 derniéres valeurs représentent en réalité -1, -2, -3. 


Nombres sur 32 bits 


Il existe des nombres tellement grands, qu'il existe une notation spéciale pour les re- 
présenter (Notation exponentielle de Knuth's) De tels nombres sont tellement grands 
qu'ils s'avérent peu pratiques pour l'ingénierie, les sciences ou les mathématiques. 


La plupart des ingénieurs et des scientifiques sont donc ravis d'utiliser la notation 
IEEE 754 pour les nombres flottants à double précision, laquelle peut représenter des 
valeurs allant jusqu'à 1.8- 10%, (En comparaison, le nombre d'atomes dans l'univers 
observable est estimé être entre 4.107? et 4.109!) 


De fait, la limite supérieure des nombres utilisés dans les opérations concrétes est 
trés trés inférieure. 


Pareil à l'époque de MS-DOS: les int 16 bits étaient utilisés pratiquement pour tout 
(indice de tableau, compteur de boucle), tandis que le type /ong sur 32 bits ne l'était 
que rarement. 


Durant l'avénement de l'architecture x86-64, il fut décidé que le type int conserve- 
rait une taille de 32 bits, probablement parce que l'utilisation d'un type int de 64 
bits est encore plus rare. 


Je dirais que les nombre sur 16 bits qui couvrent l'intervalle 0..65535 sont probable- 
ment les nombres les plus utilisés en informatique. 


Ceci étant, si vous rencontrez des nombres sur 32 bits particuliérement élevé tels 
que 0x87654321, il existe une bonne chance qu'il s'agisse : 


* || peut toujours s'agir d'un entier sur 16 bits, mais signé lorsque la valeur est 
entre OxFFFF8000 (-32768) et OxFFFFFFFF (-1). 


* une adresse mémoire (ce qui peut étre vérifié en utilisant les fonctionnalités de 
gestion mémoire du débogueur). 


* des octets compactés (ce qui peut étre vérifié visuellement). 


* un ensemble de drapeaux binaires. 
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* de la cryptographie (amateur). 
* un nombre magique (5.6.1 on page 925). 
* un nombre flottant utilisant la représentation IEEE 754 (également vérifiable). 


Il en va à peu prés de méme pour les valeurs sur 64 bits. 
donc un int sur 16 bits est suffisant pour à peu près n'importe quoi? 


Il est intéressant de constater que dans [Michael Abrash, Graphics Programming 
Black Book, 1997 chapitre 13] nous pouvons lire qu'il existe pléthore de cas pour 
lesquels des variables sur 16 bits sont largement suffisantes. Dans le méme temps, 
Michael Abrash se plaint que les CPUs 80386 et 80486 disposent de si peu de re- 
gistres et propose donc de placer deux registres de 16 bits dans un registre de 32 
bits et d'en effectuer des rotations en utilisant les instructions ROR reg, 16 (sur 
80386 et suivant) (ROL reg, 16 fonctionne également) ou BSWAP (sur 80486 et sui- 
vant). 


Cette approche rappelle celle du Z80 et de ses groupes de registres alternatifs (suf- 
fixés d'une apostrophe) vers lesquels le CPU pouvait étre basculé (et inversement) 
au moyen de l'instruction EXX. 


Taille des buffers 


Lorssqu'un programmeur doit déclarer la taille d'un buffer, il utilise généralement 
une valeur de la forme 2* (512 octets, 1024, etc.). Les valeurs de la forme 2* sont 
faciles à reconnaître (1.28.5 on page 414) en décimal, en hexadécimal et en binaire. 


Les programmeurs restent cependant des humains et conservent leur culture déci- 
male. C'est pourquoi, dans le domaine des DBMS’, la taille des champs textuels est 
souvent choisie sous la forme 10”, 100, 200 par exemple. Ils pensent simplement 
«Okay, 100 suffira, attendez, 200 ira mieux ». Et bien súr, ils ont raison. 


La taille maximale du type VARCHAR2 dans Oracle RDBMS est de 4000 caractéres 
et non de 4096. 


Il n'y a rien à redire à ceci, ce n'est qu'un exemple d'utilisation des nombres sous la 
forme d'un multiple d'une puissance de dix. 


Addresse 


Garder à l'esprit une cartographie approximative de l'occupation mémoire du proces- 
sus que vous déboguez est toujours une bonne idée. Ainsi, beaucoup d'exécutables 
win32 démarrent à l'adresse 0x00401000, donc une adresse telle que 0x00451230 
se situe probablement dans sa section exécutable. Vous trouverez des adresses de 
cette sorte dans le registre EIP. 


La pile est généralement située à une adresse inférieure à 
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Beaucoup de débogueurs sont capables d'afficher la cartographie d'occupation mé- 
moire du processus débogué, par exemple: 1.12.3 on page 109. 


Une adresse qui augmente par pas de 4 sur une architecture 32-bit, ou par pas de 8 
sur une architecture 64-bit constitue probablement l'énumération des adresses des 
éléments d'un tableau. 


Il convient de savoir que win32 n'utilise pas les adresses inférieures à 0x10000, donc 
si vous observez un nombre inférieur à cette valeur, ce ne peut étre une adresse (voir 
aussi https://msdn.microsoft.com/en-us/library/ms810627.aspx). 


De toute maniére, beaucoup de débogueurs savent vous indiquer si la valeur conte- 
nue dans un registre peut représenter l'adresse d'un élément. OllyDbg peut éga- 
lement vous afficher le contenu d'une chaîne de caracteres ASCII si la valeur du 
registre est l'adresse d'une telle chaîne. 


Drapeaux 


Si vous observez une valeur pour laquelle un ou plusieurs bits changent de valeur 
de temps en temps tel que OXABCD1234 > 0xABCD1434 et retour, il s'agit probable- 
ment d'un ensemble de drapeaux ou bitmap. 


Compactage de caractéres 


Quand strcmp() ou memcmp() copient un buffer, ils traitent 4 (ou 8) octets a la 
fois. Donc, si une chaíne de caractéres «4321» est recopié a une autre adresse, il 
adviendra un moment où vous observerez la valeur 0x31323334 dans un registre. Il 
s'agit du bloc de 4 caractéres traité comme un entier sur 32 bits. 


2.1.9 AND/OR/XOR au lieu de MOV 


OR reg, OxFFFFFFFF mets tous les bits à 1, en conséquence, peu importe ce qui se 
trouvait avant dans le registre, il sera mis à -1. OR reg, -1 est plus court que MOV 
reg, -1, donc MSVC utilise OR au lieu de ce dernier suivant, par exemple: 3.18.1 
on page 677. 


De méme, AND reg, 0 efface tous les bits, par conséquent, elle se comporte comme 
MOV reg, O0. 


XOR reg, reg, peu importe ce qui se trouvait précédemment dans le registre, efface 
tous les bits et se comporte donc comme MOV reg, 6. 


2.2 Endianness 
L'endianness (boutisme) est la facon de représenter les valeurs en mémoire. 


2.2.1 Big-endian 


La valeur 0x12345678 est représentée en mémoire comme: 
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adresse en mémoire | valeur de l'octet 
+0 0x12 
+1 0x34 
+2 0x56 
+3 0x78 


Les CPUs big-endian comprennent les Motorola 68k, IBM POWER. 


2.2.2 Little-endian 


La valeur 0x12345678 est représentée en mémoire comme: 


adresse en mémoire | valeur de l'octet 
+0 0x78 
+1 0x56 
+2 0x34 
+3 0x12 


Les CPUs little-endian comprennent les Intel x86. Un exemple important d'utilisation 
de little-endian dans ce livre est: 1.35 on page 522. 


2.2.3 Exemple 


Prenons une système Linux MIPS big-endian déjà installé et prêt dans QEMU $. 
Et compilons cet exemple simple: 


#include <stdio.h> 


int main() 
{ 
int v; 
v=123; 
printf ("%02X %02X %02X %02X\n", 
*(char*)&v, 
*(((char*)&v)+1), 
*(((char*)&v)+2), 
*(((char*)&v)+3) ): 
}; 


Aprés l'avoir lancé nous obtenons: 


root@debian-mips:~# ./a.out 
00 00 00 7B 


C'est ca. 0x7B est 123 en décimal. En architecture little-endian, 7B est le premier 
octet (vous pouvez vérifier en x86 ou en x86-64, mais ici c'est le dernier, car l'octet 
le plus significatif vient en premier. 


8Disponible au téléchargement ici: https: //people.debian.org/-aurel32/qemu/mips/ 


588 
C'est pourquoi il y a des distributions Liux séparées pour MIPS («mips » (big-endian) 
et «mipsel » (little-endian)). Il est impossible pour un binaire compilé pour une archi- 
tecture de fonctionner sur un OS avec une architecture différente. 


Il y a un exemple de MIPS big-endian dans ce livre: 1.30.4 on page 471. 


2.2.4 Bi-endian 


Les CPUs qui peuvent changer d'endianness sont les ARM, PowerPC, SPARC, MIPS, 
1A64?, etc. 


2.2.5 Convertir des données 


L'instruction BSWAP peut étre utilisée pour la conversion. 


Les paquets de données des réseaux TCP/IP utilisent la convention bit-endian, c'est 
donc pourquoi un programme travaillant en architecture little-endian doit convertir 
les valeurs. Les fonctions htonl() et htons() sont utilisées en général. 


En TCP/IP, big-endian est aussi appelé «network byte order », tandis que l'ordre des 
octets sur l'ordinateur «host byte order». Le «host byte order» est little-endian sur 
les x86 Intel et les autres architectures little-endian, mais est big-endian sur les IBM 
POWER, donc htonl() et htons() ne modifient aucun octet sur cette derniére. 


2.3 Mémoire 


Il y a 3 grands types de mémoire: 


* Mémoire globale AKA «allocation statique de mémoire». Pas besoin de l'al- 
louer explicitement, l'allocation est effectuée juste en déclarant des variables/- 
tableaux globalement. Ce sont des variables globales, se trouvant dans le seg- 
ment de données ou de constantes. Elles sont accessibles globalement (ce qui 
est considéré comme un anti-pattern). Ce n'est pas pratique pour les buffers/- 
tableaux, car ils doivent avoir une taille fixée. Les débordements de tampons 
se produisant ici le sont en général en récrivant les variables ou les buffers se 
trouvant à cóté d'eux en mémoire. Il y a un exemple dans ce livre: 1.12.3 on 
page 105. 


Stack (pile) AKA «allocation sur la pile ». L'allocation est effectuée simplement 
en déclarant des variables/ tableaux localement dans la fonction. Ce sont en 
général des variables locales de la fonction. Parfois ces variables locales sont 
aussi visibles depuis les fonctions appelées, si l'appelant passe un pointeur sur 
une variable à la fonction appelée qui va étre exécutée). L'allocation et la dé- 
allocation sont trés rapide, il suffit de décaler SP. 


Mais elles ne conviennent pas non plus pour les tampons/tableaux, car la taille 
du tampon doit étre fixée, à moins qu'alloca() (1.9.2 on page 49) (ou un 
tableau de longueur variable) ne soit utilisé. Les débordements de tampons 
écrasent en général les structures de pile importantes: 1.26.2 on page 350. 


9Intel Architecture 64 (Itanium) 
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* Heap (tas) AKA «allocation dynamique de mémoire ». L'allocation/dé-allocation 
est effectuée en appelant malloc()/free() ou new/delete en C++. Ceci est 
la méthode la plus pratique: la taille du bloc peut étre définie lors de l'exécution. 


Il est possible de redimensionner (en utilisant realloc()), mais ca peut étre 
long. Ceci est le moyen le plus lent d'allouer de la mémoire: L'allocation de 
mémoire doit gérer et mettre à jour toutes les structures de contróle pendant 
l'allocation et la dé-allocation. Les débordements de tampons écrasent en gé- 
néral ces structures. L'allocation sur le tas est aussi la source des probléme de 
fuite de mémoire: chaque bloc de mémoire doit étre dé-alloué explicitement, 
mais on peut oublier de le faire, ou le faire de maniére incorrecte. 


Un autre probléme est l'«utilisation aprés la libération »—-utiliser un bloc de 
mémoire aprés que free() ait été appelé, ce qui est trés dangereux. 


Exemple dans ce livre: 1.30.2 on page 447. 


2.4 CPU 


2.4.1 Prédicteurs de branchement 


Certains des derniers compilateurs essayent d'éliminer les instructions de saut. Il y 
a des exemples dans ce livre: 1.18.1 on page 178, 1.18.3 on page 188, 1.28.5 on 
page 424. 


C'est parce que le prédicteur de branchement n'est pas toujours parfait, donc les 
compilateurs essayent de faire sans les sauts conditionnels, si possible. 


Les instructions conditionnelles en ARM (comme ADRcc) sont une maniére, une autre 
est l'instruction x86 CMOVcc. 


2.4.2 Dépendances des données 


Les CPUs modernes sont capables d'exécuter des instructions simultanément (00E 12), 
mais pour ce faire, le résultat d'une instruction dans un groupe ne doit pas influen- 

cer l'exécution des autres. Par conséquent, le compilateur s'efforce d'utiliser des 

instructions avec le minimum d'influence sur l'état du CPU. 


C'est pourquoi l'instruction LEA est si populaire, car elle ne modifie pas les flags du 
CPU, tandis que d'autres instructions arithmétiques le font. 


2.5 Fonctions de hachage 


Un exemple trés simple est CRC32, un algorithme qui fournit des checksum plus 
«fort» à des fins de vérifications d'intégrité. Il est impossible de restaurer le texte 
d'origine depuis la valeur du hash, il a beaucoup moins d'informations: Mais CRC32 
n'est pas cryptographiquement sür: on sait comment modifier un texte afin que son 
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hash CRC32 résultant soit celui que l'on veut. Les fonctions cryptographiques sont 
protégées contre cela. 


MD5, SHA1, etc. sont de telles fonctions et elles sont largement utilisées pour ha- 

cher les mots de passe des utilisateurs afin de les stocker dans une base de données. 
En effet: la base de données d'un forum Internet ne doit pas contenir les mots de 
passe des utilisateurs (une base de données volée compromettrait tous les mots 
de passe des utilisateurs) mais seulement les hachages (donc un cracker ne pour- 
rait pas révéler les mots de passe). En outre, un forum Internet n'a pas besoin de 
connaitre votre mot de passe exactement, il a seulement besoin de vérifier si son 
hachage est le méme que celui dans la base de données, et vous donne accés s'ils 
correspondent. Une des méthodes de cracking la plus simple est simplement d'es- 
sayer de hacher tous les mots de passe possible pour voir celui qui correspond à la 
valeur recherchée. D'autres méthodes sont beaucoup plus complexes. 


2.5.1 Comment fonctionnent les fonctions à sens unique? 


Une fonction à sens unique est une fonction qui est capable de transformer une va- 
leur en une autre, tandis qu'il est impossible (ou trés difficile) de l'inverser. Certaines 
personnes éprouvent des difficultés à comprendre comment ceci est possible. Voici 
une démonstration simple. 


Nous avons un vecteur de 10 nombres dans l'intervalle 0..9, chacun est présent une 
seule fois, par exemple: 


4601357892 


L'algorithme pour une fonction à sens unique la plus simple possible est: 
* prendre le nombre à l'indice zéro (4 dans notre cas); 
* prendre le nombre à l'indice 1 (6 dans notre cas); 
* échanger les nombres aux positions 4 et 6. 


Marquons les nombres aux positions 4 et 6: 


4601357892 


Échangeons-les et nous obtenons ce résultat: 


4601753892 


En regardant le résultat, et méme si nous connaissons l'algorithme, nous ne pou- 
vons pas connaítre l'état initial de facon certaine, car les deux premiers nombres 
pourraient étre O et/ou 1, et pourraient donc participer à la procédure d'échange. 


Ceci est un exemple extrémement simplifié pour la démonstration. Les fonctions à 
sens unique réelles sont bien plus complexes. 


Chapitre 3 


Exemples un peu plus 
avancés 


3.1 Registre a zéro 


Il manque un registre à zéro dans l'architecture x86, contrairement à MIPS et ARM. 
Toutefois, il arrive souvent que lorsqu'un compilateur assigne zéro à un registre, il y 


reste jusqu'à la fin de la fonction. 


C'est le cas dans le jeu Mahjong de Windows 7 x86. EBX mis à zéro (en 0x010281BF) 
est utilisé pour initialiser les variables locales, passer un argument à zéro aux autres 
fonctions et pour comparer des valeurs avec lui 


Listing 3.1 : Mahjong.exe de Windows 7 x86 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:010281AE 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 


010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281AE 
010281B0 
010281B5 
010281BA 


sub 10281AE 


var 34 
var 30 
var 2C 
var 28 
var 24 
var 20 
var 1C 
var 18 
var 14 
var 10 
var 4 
arg 0 
arg 4 


proc near ; CODE XREF: sub 1028790+4FFp 


dword 
dword 
dword 
dword 
dword 
dword 
dword 
dword 
dword 
dword 
dword 
dword 


; sub 102909A+357p ... 


ptr -34h 
ptr -30h 
ptr -2Ch 
ptr -28h 
ptr -24h 
ptr -20h 
ptr -1Ch 
ptr -18h 
ptr -14h 
ptr -10h 
ptr -4 

ptr 8 


byte ptr 0Ch 


28h 
eax, offset — ehhandler ... 


. EH prolog3 


edi, ecx 
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.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:010281C8 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:010281EA 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0102820F 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:01028240 


.text 


.text: 
.text: 
.text: 
.text: 


010281BC 
010281BF 
010281C1 
010281C4 
010281C6 
010281C8 
010281C8 


010281CB 
010281CE 
010281D1 
010281D6 
010281D9 
010281DA 
010281DD 
010281E0 
010281E1 
010281E4 
010281E6 
010281E8 
010281E8 
010281E8 


010281ED 
010281F0 
010281F3 
010281FA 
010281FD 
01028200 
01028203 
01028209 
0102820F 
0102820F 


01028215 
01028218 
0102821B 
0102821E 
01028220 
01028226 
01028227 
01028228 
0102822A 
0102822F 
01028231 
01028233 
01028236 
01028239 


01028243 
01028246 
01028247 
0102824A 


loc 10281C8: 


loc 10281E8: 


loc 102820F: 


esi, [ebptarg 0] 
ebx, ebx 
[ebp+var_10], ebx 
[esi], ebx 

short loc 10281E8 


; CODE XREF: sub 10281AE-38j 


eax, [esi+0Ch] 
ecx, [ebp+var_10] 
dword ptr [eax+ecx*4] 
sub_10506C9 

eax, [ebp+var_10] 
ecx 

ecx, [esi+0Ch] 
[ecx+eax*4], ebx 
eax 

[ebp+var 10], eax 
eax, [esi] 

short loc 10281C8 


; CODE XREF: sub 10281AE 


[esi], ebx 
[edi+14h], ebx 
[ebp+var 34], ebx 
[ebp+var 30], ebx 
[ebp+var 2C], 10h 
[ebp+var 28], ebx 
[ebp+var 4], ebx 
[ebp+arg_0], ebx 
[edi-0BOh], ebx 
loc 10282C3 


; CODE XREF: sub 10281AE-10Fj 


eax, [edi+0BCh] 
ecx, [ebptarg 0] 
eax, [eax+ecx*4] 
[ebp+var_14], eax 
eax, ebx 
loc_10282A6 

ebx 

eax 

ecx, edi 
sub_1026B3D 

al, al 

short loc 10282A6 
[ebp+var 24], ebx 
[ebp+var 20], ebx 
[ebp-var 1C], 10h 
[ebp+var 18], ebx 
eax, [ebp+var_34] 
eax 

eax, [ebp+var 24] 
eax 


, 
, 
, 
, 


+18; 


* 


A * X* 
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:0102824B 
:0102824E 
:01028250 
:01028254 
:01028259 
:0102825C 
:0102825F 
:01028261 
:01028261 loc 1028261: 
:01028261 
:01028263 
:01028268 
:01028269 
:0102826B 
:0102826D 
:01028270 
:01028273 
:01028276 
:01028279 
:0102827C 
:0102827E 
:01028281 
:01028284 
:01028286 ; 


[ebp+var 14] 

ecx, edi 

byte ptr [ebp+var 4], 1 

sub 1026E4F 

[ebp+var 10], ebx HAE 
[ebp+var 24], ebx E 
short loc 102829B 


; CODE XREF: sub 10281AE+EBj 
OCh; Size 
sub 102E741 
ecx 
eax, ebx st 
short loc 1028286 
edx, [ebp+var_10] 
ecx, [ebp+var_18] 
ecx, [ecx+edx*4] 
edx, [ebp+var_14] 
edx, [edx+4] 
[eax], edx 
[eax+4], ecx 
[eax+8], ebx FE 
short loc 1028288 


:01028286 
:01028286 loc 1028286: 
:01028286 
:01028288 
:01028288 loc 1028288: 
:01028288 
:01028289 
:0102828B 
:01028290 
:01028293 
:01028296 
:01028299 
:0102829B 
:0102829B loc 102829B: 
:0102829B 
:0102829E 
:010282A1 
:010282A6 
:010282A6 loc 10282A6: 
:010282A6 
:010282A6 
:010282A9 
:010282AC 
:010282B1 
:010282B4 
:010282B7 
:010282BD 
:010282C3 
:010282C3 loc 10282C3: 


xor 


; CODE XREF: sub 10281AE+BDj 
eax, eax 


CODE XREF: sub 10281AE+D6j 


eax 
ecx, esi 

sub 104922B 
[ebp+var_10] 

eax, [ebp+var_10] 
eax, [ebp+var_24] 
short loc 1028261 


; CODE XREF: sub 10281AE+B1j 
ecx, [ebp+var_24] 
byte ptr [ebp+var_4], bl 
sub_10349DB 


; CODE XREF: sub 10281AE+72j 
; Sub 10281AE+83j 

[ebp+arg_ 0] 

ecx, [ebp+var_34] 

sub 104922B 

[ebp+arg_ 0] 

eax, [ebptarg 0] 

eax, [edi+0B0h] 

loc_102820F 


; CODE XREF: sub 10281AE+5Bj 
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:010282C3 
:010282C6 
:010282C8 
:010282CD 
:010282D3 
:010282D8 
:010282DB 
:010282DD 
:010282DF 
:010282E0 
:010282E6 
:010282E8 
:010282EA 
:010282EC 


:010282EC 
:010282EC 
:010282EC 
:010282ED 
:010282EE 
:010282F4 
:010282F6 
:010282F7 
:010282F7 
:010282F7 
:010282F8 
:010282FE 
:01028300 
:01028306 
:0102830B 
:01028310 
:01028312 
:01028314 
:01028315 
:01028316 
:0102831C 
:0102831E 
:0102831F 
:01028321 


loc_10282EC: 


loc_10282F7: 


[ebp+arg_4], bl 

short loc_1028337 

eax, dword_1088AD8 
esi, ds:EnableMenultem 


edi, 40002 

[eax+8], ebx yet 
short loc 10282EC 

3 ; uEnable 

edi ; ulIDEnableItem 
hMenu ; hMenu 

esi ; EnableMenultem 

3 


short loc 10282F7 


; CODE XREF: sub 10281AE+12D)j 
* 


ebx : 
edi ; ulIDEnableItem 
hMenu ; hMenu 
esi ; EnableMenultem 
ebx "EE 
; CODE XREF: sub 10281AE-13Cj 
edi ; ulIDEnableItem 
hmenu ; hMenu 


esi ; EnableMenuItem 
ecx, dword 1088AD8 
sub 1020402 


edi, 40001 

al, al 

short loc 1028321 

ebx d 

edi ; ulIDEnableItem 
hMenu ; hMenu 

esi ; EnableMenultem 
ebx "i 


short loc 102832E 


101028321 
101028321 
101028321 
101028323 
: 01028324 
:0102832A 
:0102832C 
:0102832E 
:0102832E 
:0102832E 
:0102832F 
:01028335 
:01028337 
:01028337 
:01028337 


loc 1028321: 


loc 102832E: 


loc 1028337: 


; CODE XREF: sub 10281AE+164j 


3 ; uEnable 
edi ; UIDEnableltem 
hMenu ; hMenu 
esi ; EnableMenultem 
3 ; uEnable 
; CODE XREF: sub 10281AE-*171j 
edi ; ulIDEnableItem 
hmenu ; hMenu 


esi ; EnableMenuItem 


; CODE XREF: sub 10281AE+118)j 
ecx, [ebp+var_34] 
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.text:0102833A call sub 10349DB 
.text:0102833F call . EH epilog3 
.text:01028344 retn 8 
.text:01028344 sub 10281AE endp 


À propos, IDA peut renommer un registre à l'intérieur d'une fonction (presser n) : 


Listing 3.2 : Mahjong.exe de Windows 7 x86 


.text:010281AE sub 10281AE proc near 


.text:010281AE zero = ebx 


.text:010281BF xor zero, zero "A 
.text:010281C1 mov [ebp+var 10], zero RT 
.text:010281C4 cmp [esil, zero ERG 
.text:010281C6 jbe short loc 10281E8 


3.2 Double négation 


Une facon répandue! de convertir des valeurs différentes de zéro en 1 (ou le booléen 
true) et la valeur zéro en 0 (ou le booléen false) est la déclaration !!variable : 


int convert to bool(int a) 


1 
}; 


return !!a; 


GCC 5.4 x86 avec optimisation: 


convert to bool: 


mov edx, DWORD PTR [esp+4] 
xor eax, eax 

test edx, edx 

setne al 

ret 


XOR efface toujours la valeur de retour dans EAX, méme si SETNE n'est pas déclenché. 
l.e., XOR met la valeur de retour par défaut à zéro. 


Si la valeur en entrée n'est pas égale à zéro (le suffixe -NE dans l'instruction SET), 1 
est mis dans AL, autrement AL n'est pas modifié. 


1C'est sujet à controverse, car ca conduit à du code difficile à lire 
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Pourquoi est-ce que SETNE opére sur la partie 8-bit basse du registre EAX? Parce que 
ce qui compte c'est juste le dernier bit (0 or 1), puisque les autres bits sont mis à 
zéro par XOR. 


Ainsi, ce code C/C++ peut étre récrit comme ceci: 


int convert to bool(int a) 


1 
if (a!=0) 
return 1; 
else 
return 0; 
}; 
...0U méme: 
int convert to bool(int a) 
1 
if (a) 
return 1; 
else 
return 0; 
}; 


Les compilateurs visant des CPUs n'ayant pas d'instructions similaires à SET, gé- 
nèrent dans ce cas des instructions de branchement, etc. 


3.3 const correctness 


Ceci est une fonctionnalité indúment sous-utilisée de nombreux langages de pro- 
grammation. Pour en savoir plus á ce sujet: 1, 2. 


Idéalement, tout ce que vous ne modifiez pas devrait avoir le modificateur const. Il 
est intéressant de savoir comment le const correctness est implémenté à bas niveau. 
Il n'y a pas de vérification des variables ni des arguments de fonction const lors de 
l'exécution (seulement des vérifications lors de la compilation). Mais les variables 
globales de ce type sont allouées dans le segment de données en lecture seule. 


Cet exemple va planter, car il est compilé par MSVC pour win32, la variable globale 
a est allouée dans le segment de données .rdata en lecture seule: 


const a-123; 


void f(int *i) 


1 

*i-11; // crash 
}; 
int main() 

f(&a); 

return a; 


}; 
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Les chaines C anonymes (non liées à un nom de variable) ont aussi untype const char*. 


Vous ne pouvez pas les modifier: 


#include <string.h> 
#include <stdio.h> 


void alter string(char *s) 


1 
strcpy (s, "Goodbye!"); 
printf ("Result: %s\n", s); 
}; 
int main() 
{ 
alter string ("Hello, world!\n"); 
}; 


Ce code va planter sur Linux (“segmentation fault”) et sur Windows si il compilé par 
MinGW. 


GCC pour Linux met toutes les chaînes de texte dans le segment de données . rodata, 
qui est explicitement en lecture seule (“read only data”) : 


$ objdump -s 1 


Contents of section .rodata: 
400600 01000200 52657375 6c743a20 25730a00 ....Result: %s.. 
400610 48656c6c 6f2c2077 6f726c64 210200 Hello, world!.. 


Lorsque la fonction alter string() essaye d'y écrire, une exception se produit. 


Les choses sont différentes dans le code généré par MSVC, les chaînes sont situées 
dans le segment .data, qui n'a pas de flag READONLY. Les développeurs de MSVC 
ont-ils fait un faux pas? 


C:\...>objdump -s 1.exe 


Contents of section .data: 

40b000 476f6f64 62796521 00000000 52657375 Goodbye!....Resu 
40b010 6c743a20 25730a00 48656c6c 6f2c2077 lt: %s..Hello, w 
40b020 6f726c64 21020000 00000000 00000000  orld!........... 
40b030 01000000 00000000 cOcb4000 00000000 .......... Qi. vac 


C:\...>objdump -x 1.exe 


Sections: 
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Idx Name Size VMA LMA File off Algn 
0 .text 00006d2a 00401000 00401000 200000400 2**2 
CONTENTS, ALLOC, LOAD, READONLY, CODE 
1 .rdata 00002262 00408000 00408000 200007200 2**2 
CONTENTS, ALLOC, LOAD, READONLY, DATA 
2 .data 00000e00 0040b000 0040b000 200009600 2**2 
CONTENTS, ALLOC, LOAD, DATA 
3 .reloc 00000b98 0040e000 0040e000 20000a400 2**2 


CONTENTS, ALLOC, LOAD, READONLY, DATA 


Toutefois, MinGW n'a pas cette erreur et alloue les chaînes de texte dans le segment 
. rdata. 


3.3.1 Chaines const se chevauchant 


Le fait est qu'une chaine C anonyme a un type const (1.5.1 on page 13), et que les 
chaínes C allouées dans le segment des constantes sont garanties d'étre immuables, 
a cette conséquence intéressante: Le compilateur peut utiliser une partie spécifique 
de la chaine. 


Voyons cela avec un exemple: 


#include <stdio.h> 


int f1() 
{ 
printf ("world\n"); 
} 
int f2() 
1 
printf ("hello world\n"); 
} 
int main() 
1 
f1(); 
f2(); 
} 


La plupart des compilateurs C/C++ (MSVC inclus) allouent deux chaînes, mais voyons 
ce que fait GCC 4.8.1: 


Listing 3.3 : GCC 4.8.1 + IDA 


f1 proc near 

S = dword ptr -1Ch 
sub esp, 1Ch 
mov [esp+1Ch+s], offset s ; “world\n" 
call | puts 


add esp, 1Ch 
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retn 

f1 endp 

f2 proc near 

S = dword ptr -1Ch 
sub esp, 1Ch 
mov [esp+1Ch+s], offset aHello ; "hello " 
call | puts 
add esp, 1Ch 
retn 

f2 endp 

aHello db 'hello ' 

S db 'world',0xa,0 


Effectivement: lorsque nous affichons la chaine «hello world » ses deux mots sont 
positionnés consécutivement en mémoire et l'appel à puts() depuis la fonction f2() 
n'est pas au courant que la chaíne est divisée. En fait, elle n'est pas divisée; elle l'est 
virtuellement, dans ce listing. 


Lorsque puts() est appelé depuis f1(), il utilise la chaine «world » ainsi qu'un octet 
à Zéro. puts() ne sait pas qu'il y a quelque chose avant cette chaîne! 


Cette astuce est souvent utilisée, au moins par GCC, et permet d'économiser de la 
mémoire. C'est proche du string interning. 


Un autre exemple concernant ceci se trouve là: 3.4. 


3.4 Exemple strstr() 
Revenons au fait que GCC peut parfois utiliser une partie d'une chaíne de caracteres: 
3.3.1 on the preceding page. 


La fonction strstr() de la bibliothéque standard C/C++ est utilisée pour trouver une 
occurrence dans une chaîne. C'est ce que nous voulons faire: 


#include <string.h> 
#include <stdio.h> 


int main() 

{ 
char *s="Hello, world!"; 
char *w=strstr(s, "world"); 


printf ("%p, [%s]\n", s, s); 
printf ("%p, [%s]\n", w, w); 
y; 


La sortie est: 
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0x8048530, [Hello, world!] 
0x8048537, [world!] 


La différence entre l'adresse de la chaíne originale et l'adresse de la sous-chaíne que 
strstr() a renvoyé est 7. En effet, la chaíne «Hello, » a une longueur de 7 caracteres. 


La fonction printf() lors du second appel n'a aucune idée qu'il y a des autres 
caracteres avant la chaîne passée et elle affiche des caractères depuis le milieu 
de la chaine originale jusqu'à la fin (marquée par un octet à zéro). 


3.5 qsort() revisité 


(Revenons au fait que l'instruction CMP fonctionne comme SUB : 1.12.4 on page 119.) 


Maintenant que vous étes déjà familier avec la fonction qsort() (1.33 on page 495), 
voici un bel exemple oü l'opération de comparaison (CMP) peut étre remplacée par 
l'opération de soustraction (SUB). 


/* fonction de comparaison qsort int */ 
int int cmp(const void *a, const void *b) 
1 
const int *ia = (const int *)a; // casting de types de pointeur 
const int *ib = (const int *)b; 
return *ia - *ib; 
/* comparaison d'entier: renvoie négatif si if b » a 
et positif si a » b */ 
} 


(http://www.anyexample.com/programming/c/qsort sorting array of strings 
integers and structs.xml http://archive.is/Hh3jz ) 


Aussi, une implémentation typique de strcmp() (tiré d'OpenBSD) : 


int 
strcmp(const char *s1, const char *s2) 
1 

while (*s1 == *s2++) 

if (*s1++ == 0) 
return (0); 

return (*(unsigned char *)s1 - *(unsigned char *)--s2); 

} 


3.6 Conversion de température 


Un autre exemple très populaire dans les livres de programmation est un petit pro- 
gramme qui convertit une température de Fahrenheit vers Celsius ou inversement. 


5- (F - 32) 
9 


C= 
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Nous pouvons aussi ajouter une gestion des erreurs simples: 1) nous devons vérifier 
si l'utilisateur a entré un nombre correct; 2) nous devons tester si la température en 
Celsius n'est pas en dessous de -273 (qui est en dessous du zéro absolu, comme vu 
pendant les cours de physique à l'école) 


La fonction exit() termine le programme instantanément, sans retourner à la fonc- 
tion appelante. 


3.6.1 Valeurs entieres 


#include <stdio.h> 
#include <stdlib.h> 


int main() 
{ 
int celsius, fahr; 
printf ("Enter temperature in Fahrenheit: An"); 
if (scanf ("%d", &fahr) !=1) 
{ 
printf ("Error while parsing your input\n"); 
exit(0); 
}; 


celsius = 5 * (fahr-32) / 9; 


if (celsius<-273) 
1 
printf ("Error: incorrect temperature!\n"); 
exit(0); 
}; 
printf ("Celsius: %d\n", celsius); 
}; 


MSVC 2012 x86 avec optimisation 


Listing 3.4 : MSVC 2012 x86 avec optimisation 


$SG4228 DB ‘Enter temperature in Fahrenheit:', 0aH, OOH 
$SG4230 DB '%d', OOH 
$SG4231 DB ‘Error while parsing your input', 0aH, 00H 
$SG4233 DB 'Error: incorrect temperature!', 0aH, 00H 
$SG4234 DB ‘Celsius: %d', OaH, OOH 
_fahr$ = -4 ; taille = 4 
_main PROC 
push ecx 
push esi 
mov esi, DWORD PTR imp printf 
push OFFSET $5G4228 ; 'Enter temperature in Fahrenheit: ' 
call esi ; appeler printf() 
lea eax, DWORD PTR _fahr$[esp+12] 


push eax 
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oe 
a 


push OFFSET $5G4230 Po! 
call DWORD PTR imp scanf 


add esp, 12 
cmp eax, 1 
je SHORT $LN2@main 
push OFFSET $SG4231 ; 'Error while parsing your input' 
call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN9@main: 
$LN2@main: 
mov eax, DWORD PTR _fahr$[esp+8] 
add eax, -32 ; ffffffeoH 
lea ecx, DWORD PTR [eax+eax*4] 
mov eax, 954437177 ; 38e38e39H 
imul ecx 
sar edx, 1 
mov eax, edx 
shr eax, 31 ; 0000001fH 
add eax, edx 
cmp eax, -273 ; fffffeefH 
jge SHORT $LN1@main 
push OFFSET $5G4233 ; 'Error: incorrect temperature! ' 
call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN10@main: 
$LN1@main: 
push eax 
push OFFSET $SG4234 ; 'Celsius: %d' 
call esi ; appeler printf() 
add esp, 8 
; renvoyer O - d'après le standard C99 
xor eax, eax 
pop esi 
pop ecx 
ret 0 
$LN8@main: 
main  ENDP 


Ce que l'on peut en dire: 


* L'adresse de printf() est d'abord chargée dans le registre ESI, donc les futurs 
appels à printf() seront faits juste par l'instruction CALL ESI. C'est une tech- 
nique trés populaire des compilateurs, possible si plusieurs appels consécutifs 
vers la méme fonction sont présents dans le code, et/ou s'il y a un registre 


disponible qui peut étre utilisé pour ca. 


* Nous voyons l'instruction ADD EAX, -32 à l'endroit où 32 doit être soustrait de 
la valeur. EAX = EAX +(-32) est équivalent à EAX = EAX -32 et curieusement, 
le compilateur a décidé d'utiliser ADD au lieu de SUB. Peut-étre que ca en vaut 
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la peine, difficile d'en étre sür. 


L'instruction LEA est utilisée quand la valeur est multipliée par 5: lea ecx, 
DWORD PTR [eax+eax*4]. Oui, i + à + 4 équivaut à ¿+ 5 et LEA s'exécute plus 
rapidement que IMUL. 

D'ailleurs, la paire d'instructions SHL EAX, 2 / ADD EAX, EAX peut aussi être 
utilisée ici— certains compilateurs le font. 


La division par l'astuce de la multiplication (3.12 on page 636) est aussi utilisée 
ici. 


main() retourne O si nous n'avons pas return 0 à la fin. Le standard C99 nous 
dit [ISO/IEC 9899:TC3 (C C99 standard), (2007)5.1.2.2.3] que main() va retour- 
ner O dans le cas ou la déclaration return est manquante. Cette règle fonc- 
tionne uniquement pour la fonction main(). 


Cependant, MSVC ne supporte pas officiellement C99, mais peut-étre qu'il le 
supporte partiellement? 
MSVC 2012 x64 avec optimisation 


Le code est quasiment le méme, mais nous trouvons une instruction INT 3 aprés 
chaque appel à exit(). 


xor ecx, ecx 
call QWORD PTR imp exit 
int 3 


INT 3 est un point d'arrét du debugger. 


C'est connu que exit() est l'une des fonctions qui ne retourne jamais ?, donc si 
elle le fait, quelque chose de vraiment étrange est arrivé et il est temps de lancer le 
debugger. 


3.6.2 Valeurs à virgule flottante 


#include <stdio.h> 
#include <stdlib.h> 


int main() 
{ 
double celsius, fahr; 
printf ("Enter temperature in Fahrenheit:\n"); 
if (scanf ("%lf", Gfahr)!=1) 
1 
printf ("Error while parsing your input\n"); 
exit(0); 
}; 


celsius = 5 * (fahr-32) / 9; 


2une autre connue est longjmp() 
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if (celsius<-273) 
1 
printf ("Error: incorrect temperature!\n"); 
exit(0); 
}; 
printf ("Celsius: %lf\n", celsius); 
}; 


MSVC 2010 x86 utilise des instructions FPU.. 
Listing 3.5 : MSVC 2010 x86 avec optimisation 


$SG4038 DB ‘Enter temperature in Fahrenheit:', OaH, OOH 
$SG4040 DB '%lf', OOH 
$5G4041 DB ‘Error while parsing your input', 0aH, 00H 
$SG4043 DB ‘Error: incorrect temperature!', 0aH, 00H 
$SG4044 DB 'Celsius: %lf', OaH, OOH 
__real@c071100000000000 DQ 0c071100000000000r ; -273 
. realg4022000000000000 DQ 04022000000000000r ; 9 
. reale4014000000000000 DQ 04014000000000000r $5 
__real@4040000000000000 DQ 04040000000000000r 1 32 
 fahr$ = -8 ; taille = 8 
_main PROC 
sub esp, 8 
push esi 
mov esi, DWORD PTR imp printf 
push OFFSET $SG4038 ; 'Enter temperature in Fahrenheit:' 
call esi ; appeler printf() 
lea eax, DWORD PTR _fahr$[esp+16] 
push eax 
push OFFSET $SG4040 > -i E 
call DWORD PTR imp scanf 
add esp, 12 
cmp eax, 1 
je SHORT $LN2@main 
push OFFSET $SG4041 ; 'Error while parsing your input' 
call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN2@main: 
fld QWORD PTR _fahr$[esp+12] 


fsub QWORD PTR  reale4040000000000000 ; 32 


fmul QWORD PTR  realQ4014000000000000 ; 5 

fdiv QWORD PTR  realQ4022000000000000 ; 9 

fld QWORD PTR __real@c071100000000000 ; -273 

fcomp ST(1) 

fnstsw ax 

test ah, 65 ; 00000041H 

jne SHORT $LN1@main 

push OFFSET $5G4043 ; 'Error: incorrect temperature! ' 


fstp ST(0) 
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'Celsius: %lf' 


call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN1@main: 
sub esp, 8 
fstp QWORD PTR [esp] 
push OFFSET $SG4044 ; 
call esi 
add esp, 12 
; renvoyer O0 - d'après le standard C99 
xor eax, eax 
pop esi 
add esp, 8 
ret 0 
$LN10@main: 
main  ENDP 


...mais MSVC 2012 utilise à la place des instructions SIMD : 


Listing 3.6 : MSVC 2010 x86 avec optimisation 


$SG4228 DB ‘Enter temperature in Fahrenheit:', 0aH, OOH 
$SG4230 DB '%lf', OOH 

$SG4231 DB ‘Error while parsing your input', 0aH, 00H 
$5G4233 DB ‘Error: incorrect temperature!', 0aH, OOH 
$SG4234 DB ‘Celsius: %lf', OaH, OOH 
__real@c071100000000000 DQ 0c071100000000000r ; -273 
__real@4040000000000000 DQ 04040000000000000r ; 32 
__real@4022000000000000 DQ 04022000000000000r ; 9 
__real@4014000000000000 DQ 04014000000000000r $25 


_fahr$ = -8 ; taile = 8 
_main PROC 
sub esp, 8 
push esi 
mov esi, DWORD PTR imp printf 
push OFFSET $SG4228 : 
call esi 
lea eax, DWORD PTR _fahr$[esp+16] 
push eax 
push OFFSET $SG4230 > ‘Lf! 
call DWORD PTR imp scanf 
add esp, 12 
cmp eax, 1 
je SHORT $LN2@main 
push OFFSET $SG4231 : 
call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN9@main: 
$LN2@main: 
movsd xmm1, QWORD PTR _fahr$[esp+12] 


‘Enter temperature in Fahrenheit: ' 
; appeler printf() 


‘Error while parsing your input’ 
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subsd  xmml, QWORD PTR _ real(e4040000000000000 ; 32 


movsd xmm0, QWORD PTR _ real@c071100000000000 ; -273 
mulsd xmm1, QWORD PTR _ real@4014000000000000 ; 5 
divsd xmm1, QWORD PTR __real@4022000000000000 ; 9 
comisd xmmO, xmml 
jbe SHORT $LN1@main 
push OFFSET $5G4233 ; ‘Error: incorrect temperature! ' 
call esi ; appeler printf() 
add esp, 4 
push 0 
call DWORD PTR imp exit 
$LN10@main: 
$LN1@main: 
sub esp, 8 
movsd QWORD PTR [esp], xmml 
push OFFSET $SG4234 ; ‘Celsius: %lf' 
call esi ; appeler printf() 
add esp, 12 
; renvoyer 0 - d'après le standard C99 
xor eax, eax 
pop esi 
add esp, 8 
ret 0 
$LN8@main: 
main  ENDP 


Bien sür, les instructions SIMD sont disponibles dans le mode x86, incluant celles qui 
fonctionnent avec les nombres à virgule flottante. 


C'est un peu plus simple de les utiliser pour les calculs, donc le nouveau compilateur 
de Microsoft les utilise. 


Nous pouvons aussi voir que la valeur -273 est chargée dans le registre XMMO trop 
tót. Et c'est OK, parce que le compilateur peut mettre des instructions dans un ordre 
différent de celui du code source. 


3.7 Suite de Fibonacci 


Un autre exemple trés utilisé dans les livres de programmation est la fonction ré- 
cursive qui génére les termes de la suite de Fibonacci?. Cette suite est trés simple: 
chaque nombre consécutif est la somme des deux précédents. Les deux premiers 
termes sont 0 et 1 ou 1 et 1. 


La suite commence comme ceci: 
0,1,1,2,3,5,8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181... 


3.7.1 Exemple #1 


L'implémentation est simple. Ce programme génére la suite jusqu'à 21. 


3http://oeis.org/A000045 
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#include <stdio.h> 


void fib (int a, int b, int limit) 


{ 
printf ("%d\n", a+b); 
if (atb > Limit) 
return; 
fib (b, a+b, limit); 
}; 
int main() 
{ 
printf ("O\ni\ni\n"); 
fib (1, 1, 20); 
}; 
Listing 3.7 : MSVC 2010 x86 
a$ = 8 ; size = 4 
_b$ = 12 : size = 4 
limit$ = 16 ; size = 4 
fib PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR a$[ebp] 
add eax, DWORD PTR b$[ebp] 
push eax 
push OFFSET $5G2643 
call DWORD PTR imp printf 
add esp, 8 
mov ecx, DWORD PTR a$[ebp] 
add ecx, DWORD PTR b$[ebp] 
cmp ecx, DWORD PTR  limit$[ebp] 
jte SHORT $LN1@fib 
jmp SHORT $LN2@fib 
$LN1@fib: 
mov edx, DWORD PTR  limit$[ebp] 
push edx 
mov eax, DWORD PTR a$[ebp] 
add eax, DWORD PTR _b$[ebp] 
push eax 
mov ecx, DWORD PTR _b$[ebp] 
push ecx 
call fib 
add esp, 12 
$LN2Gfib: 
pop ebp 
ret 0 
fib ENDP 
main PROC 
push ebp 
mov ebp, esp 
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push 
call 
add 
push 
push 
push 
call 
add 
xor 
pop 
ret 
main  ENDP 


OFFSET $5G2647 ; "O\n1\n1\n" 
DWORD PTR imp printf 

esp, 4 

20 


Nous allons illustrer les frames de pile avec ceci. 
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Chargeons cet exemple dans OllyDbg et tracons jusqu'au dernier appel de f () 


CPU - main thread, module fib 


OOFD1000 
aarpiaoi 


ping 
BBOFD1803 Este 


MOU EAX, DWORD PTR SS: [EEP+8] exp 
ADD EAX, DWORD PTR SS:LEBP*CI HERB 
PUSH EAX | EE) 
PUSH fib. 9@FD3000 poeanana 
CALL DUORD PTR DS: C<aMSUCR1@9.print#>2 [Lori ESO 
, papagaai 
MOU ECX, DWORD PTR SS: [EBP+8] 
ADD ECX, DWORD PTR SS: CEBP+C1 reia LD IE 
SE ECH, DWORD Ear our OØFD103D f ib.G@FD1930 
ES 0028 32bit OFFFFFFFF) 
Hoy EDX, DWORD PTR SS: LEBP«101 Ec pem cou gp 
52 PUSH EDS GS Goce Sebit DLFFFFFFFF) 
8B45 G8 MOU EAX, DWORD PTR SS: [EEP+8] l 
0345 BC ADD EAX, DWORD PTR SS: CEBP+C] e A. 


5à PUSH EAX 
Ee et prese er DUE EDS t LastErr ERROR SUCCESS (88888000) 
ES C7EFFFFF |CALL fib gaFD1000 00000202 (NO,NB,NE,A,NS, PO, GE, G) 
83C4 ac ESP, aC 

POP EBP 


A te es A 


a a a 

03000 " BB35F944| aaaaaaas 
aarDasaas Bassr94s| 68086860 
aarDsaia DO35F94C| aaaaani4 


RETURN fib.D9FD1039 f ib. 0ØFD1000 
RETURN fib.D9FD1039 from fib.00FD1000 
RETURN f ib. 0ØFD1039 f ib. 0ØFD1000 
RETURN fib. 0ØFD1039 from fib.090FD1000 
RETURN f ib. 0ØFD105C f ib. 0ØFD1000 


RETURN fib.@GFD1108 from fib.090FD1040 


Pointer to nest SEH record 
SE handler 


DO3SF9FC|| 74C1338A| RETURN to kernel32.74C1338R 


Fig. 3.1: OllyDbg : dernier appel de f() 
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Examinons plus attentivement la pile. Les commentaires ont été ajoutés par l'auteur 
de ce livre ^ : 


0035F940 . 00FD1039 RETURN to fib.00FD1039 from fib.00FD1000 

0035F944 00000008 ler argument: a 

0035F948  0000000D 2nd argument b 

0035F94C 00000014 3éme argument: limit 

0035F950 /0035F964 registre EBP sauvé 

0035F954 |00FD1039 RETURN to fib.00FD1039 from fib.00FD1000 

0035F958 |00000005 ler argument: a 

0035F95C |00000008 2nd argument: b 

0035F960 |00000014 3ème argument: limit 

0035F964 ]0035F978 registre EBP sauvé 

0035F968 |00FD1039 RETURN to fib.00FD1039 from fib.00FD1000 

0035F96C 100000003 ler argument: a 

0035F970 |00000005 2nd argument: b 

0035F974 |00000014 3ème argument: limit 

0035F978 ]0035F98C registre EBP sauvé 

0035F97C  |00FD1039 RETURN to fib.00FD1039 from fib.00FD1000 

0035F980 |00000002 ler argument: a 

0035F984 |00000003 2nd argument: b 

0035F988 |00000014 3ème argument: limit 

0035F98C ]0035F9A0 registre EBP sauvé 

0035F990 .]00FD1039 RETURN to fib.00FD1039 from fib.00FD1000 

0035F994 100000001 ler argument: a 

0035F998 |00000002 2nd argument: b 

0035F99C 100000014 3ème argument: limit 

0035F9A0 ]0035F9B4 registre EBP sauvé 

0035F9A4 |O0FD105C RETURN to fib.00FD105C from fib.00FD1000 

0035F9A8 |00000001 ler argument: a N 

0035F9AC |00000001 2nd argument: b | préparé dans main() pour f1() 

0035F9BO 100000014 3ème argument: limit / 

0035F9B4 ]0035F9F8 registre EBP sauvé 

0035F9B8 |00FD11DO RETURN to fib.00FD11D0 from fib.00FD1040 

0035F9BC |00000001 main() ler argument: argc \ 

0035F9CO |006812C8 main() 2nd argument: argv | préparé dans CRT pour > 
s main() 

0035F9C4 100682940 main() 3ème argument: envp / 


La fonction est récursive °, donc la pile ressemble à un «sandwich ». 


Nous voyons que l'argument limit est toujours le méme (0x14 ou 20), mais que les 
arguments a et b sont différents pour chaque appel. 


Il y a aussi ici le RA-s et la valeur sauvée de EBP. OllyDbg est capable de déterminer 
les frames basés sur EBP, donc il les dessine ces accolades. Les valeurs dans chaque 
accolade constituent la frame de pile, autrement dit, la zone de la pile qu'un appel 
de fonction utilise comme espace dédié. 


Nous pouvons aussi dire que chaque appel de fonction ne doit pas accéder les élé- 
ments de la pile au delà des limites de son bloc (en excluant les arguments de la 


^À propos, il est possible de sélectionner plusieurs entrées dans OllyDbg et de les copier dans le presse- 
papier (Crtl-C). C'est ce qui a été fait par l'auteur pour cet exemple. 
5i.e., elle s'appelle elle-méme 
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fonction), bien que cela soit techniquement possible. 
C'est généralement vrai, à moins que la fonction n'ait des bugs. 


Chaque valeur sauvée de EBP est l'adresse de la structure de pile locale précédente: 
c'est la raison pour laquelle certains débogueurs peuvent facilement diviser la pile 
en blocs et afficher chaque argument de la fonction. 


Comme nous le voyons ici, chaque exécution de fonction prépare les arguments pour 
l'appel de fonction suivant. 


À la fin, nous voyons les 3 arguments de main(). argc vaut 1 (oui, en effet, nous 
avons lancé le programme sans argument sur la ligne de commande). 


Ceci peut conduire facilement à un débordement de pile: il suffit de supprimer (ou 
commenter) le test de la limite et ca va planter avec l'exception 0xC00000FD (stack 
overflow). 


3.7.2 Exemple +2 


Ma fonction a quelques redondances, donc ajoutons une nouvelle variable locale 
next et remplacons tout les «a+b» avec elle: 


#include <stdio.h> 


void fib (int a, int b, int limit) 


{ 
int next=a+b; 
printf ("%d\n", next); 
if (next > limit) 
return; 
fib (b, next, limit); 
}; 
int main() 
{ 
printf ("O\ni\ni\n"); 
fib (1, 1, 20): 
}; 


C'est la sortie de MSVC sans optimisation, donc la variable next est allouée sur la 
pile locale: 


Listing 3.8 : MSVC 2010 x86 


_next$ = -4 : size = 4 
_a$ = 8 ; size = 4 
_b$ = 12 : size = 4 
_limit$ = 16 ; size = 4 
_fib PROC 
push ebp 
mov ebp, esp 
push ecx 
mov eax, DWORD PTR _a$[ebp] 


add eax, DWORD PTR b$[ebp] 
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mov 
mov 
push 
push 
call 
add 
mov 
cmp 
jle 
jmp 
$LN1@fib: 
mov 
push 
mov 
push 
mov 
push 
call 
add 
$LN2Gfib: 
mov 
pop 
ret 
fib ENDP 


_main PROC 
push 
mov 
push 
call 
add 
push 
push 
push 
call 
add 
xor 
POP 
ret 

main  ENDP 


DWORD PTR next$[ebp], eax 
ecx, DWORD PTR next$[ebp] 
ecx 

OFFSET $SG2751 ; '%d' 

DWORD PTR imp printf 
esp, 8 

edx, DWORD PTR next$[ebp] 
edx, DWORD PTR  limit$[ebp] 
SHORT $LN1@fib 

SHORT $LN2@fib 


eax, DWORD PTR  limit$[ebp] 
eax 

ecx, DWORD PTR next$[ebp] 
ecx 

edx, DWORD PTR b$[ebp] 

edx 

fib 

esp, 12 


esp, ebp 
ebp 
0 


ebp 

ebp, esp 

OFFSET $SG2753 ; "O\n1\n1\n" 
DWORD PTR imp printf 

esp, 4 

20 
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Chargeons-le á nouveau dans OllyDbg : 


GGEG1041 
GDE 1042 


POP EBP. 
| RETN 
INTS 


ADD EAX, DWORD PTR SS: [EBP+C] 
MOU DWORD PTR SS: [EBP-4],EAX 
MOU ECX, DWORD PTR SS: [EBP-4] 
PUSH ECX 

PUSH f ib2. 69E93008 

CALL DWORD PTR DS: [<8.MSUCR10B8.printf>1 
ADD ESP,8 

MOU EDX,DWORD PTR SS: CEBP-4] 
CMP EDX, DWORD PTR SS: [EBP+10] 
JLE SHORT fib2.00E61029 

JMP SHORT fib2.00E6163D 

MOV EAX, DWORD PTR SS: [EBP+10] 
PUSH ERX 

MOV ECX, DWORD PTR SS: [EBP-4] 
PUSH ECX 

MOV EDX, DWORD PTR SS: CEBP+C] 
PUSH EDX 

CALL f ib2.00E01000 

ADD ESP, ØC 

MOU ESP,EBP 


VEI: AU 
CEE] 
6Fa8S617 
90900015 
20808848 
BB29FC14 
BB29FC28 
96009081 
00E03378 


00E01040 


ES 6626 
Cs 0023 
SS 6626 
DS 0026 
FS 0053 
GS 0026 


LastErr 
9806262 


Return to @BEG193A (f ib2.6GE6163A) 


aooeaaos| 


200909090 
66880814 
100909090 
aa2srcaa 
aaEaiasn 
aaaaaaas 
aaaaaaas 
aaaanai4 
26080088 
aa2srcos 
DOEGIOSA 
60080883 
aaaaaaas 
66680814 
aaaaaaas 
aa2src?a 
aakatasn 
aaaaaaa2 
60080083 
00000014 
aaacaaas 
aa2srces 


aaaaoaal4 
aaaaaaa2 
aa29rcoc 


m 


00000014 
aa2srcEa 
GGEG11EG 
26684881 
aaasi2cs 
aaas2940 
BFF371AC 
aaaaaaaa 
gogogo 
TEFDEGBaaG 
aaaaaaaa 
aaaaaaaa 
aa2srcba 
E9996B77 
BOB29FD1C 


HSUCR188.6FB885617 


fib2.00E03378 
fib2.00E01040 


32bit O(FFFFFFFE) 
S2bit O(FFFFFFFF) 
32bit O(FFFFFFFF) 
32bit BCFFFFFFFF) 
32bit 7EFODGGG( FFF) 
32bit OC FFFFFFFF) 


ERROR SUCCESS (66868006) 
(NO, NB, NE, A, NS, PO, GE, G) 


RETURN fib2.00E0103A from fib2.00E0100€ 


RETURN fib2.00E0103A from fib2.00E0100t 


RETURN fib2.00E0103A from fib2.00E0100t 


RETURN fib2.00E0103A from fib2.00E0100t 


RETURN fib2.00EG106C from fib2.00E60100t 


RETURN fib2.00E011E0 from fib2.00E0105t 


Pointer to next SEH record 


Fig. 3.2: OllyDbg : dernier appel de f() 


Maintenant, la variable next est présente dans chaque frame. 
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Examinons plus attentivement la pile. L'auteur a de 


nouveau ajouté ses commen- 


taires: 

0029FC14  00E0103A RETURN to fib2.00E0103A from fib2.00E01000 

0029FC18 00000008 ler argument: a 

0029FC1C 0000000D 2nd argument: b 

0029FC20 00000014 3éme argument: limit 

0029FC24  0000000D variable "next" 

0029FC28 /0029FC40 registre EBP sauvé 

0029FC2C |00E0103A RETURN to fib2.00E0103A from fib2.00E01000 

0029FC30 |00000005 ler argument: a 

0029FC34 |00000008 2nd argument: b 

0029FC38 |00000014 3ème argument: limit 

0029FC3C 100000008 "next" variable 

0029FC40 ]0029FC58 registre EBP sauvé 

0029FC44 |00E0103A RETURN to fib2.00E0103A from fib2.00E01000 

0029FC48 |00000003 ler argument: a 

0029FC4C |00000005 2nd argument: b 

0029FC50 |00000014 3ème argument: limit 

0029FC54 |00000005 variable "next" 

0029FC58 ]0029FC70 registre EBP sauvé 

0029FC5C |00E0103A RETURN to fib2.00E0103A from fib2.00E01000 

0029FC60 100000002 ler argument: a 

0029FC64 100000003 2nd argument: b 

0029FC68 |00000014 3ème argument: limit 

0029FC6C 100000003 variable "next" 

0029FC70 ]0029FC88 registre EBP sauvé 

0029FC74 |00E0103A RETURN to fib2.00E0103A from fib2.00E01000 

0029FC78 |00000001 ler argument: a N 

0029FC7C 100000002 2nd argument: b | préparé dans f1() pour le 2 
y prochain appel à f1() 

0029FC80 |00000014 3ème argument: limit / 

0029FC84 100000002 variable "next" 

0029FC88 ]0029FC9C registre EBP sauvé 

0029FC8C ]|00F0106C RETURN to fib2.00E0106C from fib2.00E01000 

0029FC90 100000001 ler argument: a N 

0029FC94 |00000001 2nd argument: b | préparé dans main() pour f1() 

0029FC98 100000014 3ème argument: limit / 

0029FC9C ]0029FCEO registre EBP sauvé 

0029FCAO |00E011E0 RETURN to fib2.00E011E0 from fib2.00E01050 

0029FCA4 |00000001 main() ler argument: argc \ 

0029FCA8 |000812C8 main() 2nd argument: argv | préparé dans CRT pour v 
& main() 

0029FCAC |00082940 main() 3éme argument: envp / 


Voici ce que l'on voit: la valeur next est calculée dans chaque appel de la fonction, 
puis passée comme argument b au prochain appel. 
3.7.3 Résumé 


Les fonctions récursives sont esthétiquement jolies, mais techniquement elles peuvent 
dégrader les performances à cause de leur usage intensif de la pile. Quiconque qui 
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écrit du code dont la perfomance est critique devrait probablement éviter la récur- 
sion. 


Par exemple, j'ai écrit une fois une fonction pour chercher un noeud particulier dans 
un arbre binaire. Bien que la fonction récursive avait l'air élégante, il y avait du temps 
passé à chaque appel de fonction pour le prologue et l'épilogue, elle fonctionnait 
deux ou trois fois plus lentement que l'implémentation itérative (sans récursion). 


A propos, c'est la raison pour laquelle certains compilateurs fonctionnels LP® (ou 
la récursion est trés utilisée) utilisent les appels terminaux. Nous parlons d'appel 
terminal lorsqu'une fonction a un seul appel à elle-méme, situé à sa fin, comme: 


Listing 3.9 : Scheme, exemple copié/collé depuis Wikipédia 


;; factorial : nombre -» nombre 
;; pour calculer le produit de tous les entiers 
;; positifs inférieurs ou égaux à n. 
(define (factorial n) 
(if (=n 1) 
1 
(* n (factorial (- n 1))))) 


Les appels terminaux sont importants car le compilateur peut retravailler facilement 
ce code en un code itératif, pour supprimer la récursion. 


3.8 Exemple de calcul de CRC32 


C'est une technique trés répandue de calcul de hachage basée sur une table CRC32’. 


/* By Bob Jenkins, (c) 2006, Public Domain */ 


#include <stdio.h> 
#include <stddef.h> 
#include <string.h> 


typedef unsigned long ub4; 
typedef unsigned char ubl; 


static const ub4 crctab[256] = { 
0x00000000, 0x77073096, Oxee0e612c, 0x990951ba, 0x076dc419, 
0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 
O0xe0d5e91e, Ox97d2d988, 0x09b64c2b, Ox7eb17cbd, Oxe7b82d07, 
0x90bf1d91, Ox1db71064, 0x6ab020f2, 0xf3b97148, Ox84be41de, 
Oxladad47d, Ox6ddde4eb, Oxf4d4b551, 0x83d385c7, 0x136c9856, 
0x646ba8c0, Oxfd62f97a, 0x8a65c9ec, Ox14015c4f, 0x63066cd9, 
Oxfa0f3d63, 0x8d080df5, Ox3b6e20c8, 0x4c69105e, 0xd56041e4, 
0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, Oxa50ab56b, 
0x35b5a8fa, 0x42b2986c, Oxdbbbc9d6, Oxacbcf940, 0x32d86ce3, 
0x45df5c75, Oxdcd60dcf, Oxabd13d59, 0x26d930ac, 0x51de003a, 
0xc8d75180, Oxbfd06116, Ox21b4f4b5, 0x56b3c423, Oxcfba9599, 


SLISP, Python, Lua, etc. 
7Le code source provient d'ici: http://burtleburtle.net/bob/c/crc.c 
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Oxb8bda50f, 
0x2f6f7c87, 
0x01db7106, 
Ox9fbfe4a5, 
0xe10e9818, 
Ox6b6b51f4, 
0x1b01a57b, 
Ox8bbeb8ea, 
Oxfbd44c65, 
Ox4adfa541, 
0x346ed9fc, 
Oxaa0a4c5f, 
0xc90c2086, 
Ox5edef90e, 
0x2eb40d81, 
0x03b6e20c, 
0x73dc1683, 
Oxe40ecfOb, 
0x8708a3d2, 
0x196c3671, 
0x67dd4acc, 
0xd6d6a3e8, 
0xa6bc5767, 
0x36034af6, 
0x4669be79, 
0xcc0c7795, 
0xb2bd0b28, 
0x2cd99e8b, 
0x026d930a, 
0x95bf4a82, 
Oxe5d5be0d, 
0x68ddb3f8, 
0x18b74777, 
0x8f659eff, 
0xd70dd2ee, 
0x4969474d, 
0x37d83bf0, 
Oxbdbdf21c, 
Oxcdd70693, 
0x5d681b02, 
0x2d02ef8d 
Ji 


/* how to derive the values in crctab[] from polynomial 0xedb88320 */ 


0x2802b89e, 
0x58684c11, 
0x98d220bc, 
0xe8b8d433, 
0x7f6aO0dbb, 
0x1c6c6162, 
0x8208f4c1, 
Oxfcb9887c, 
0x4db26158, 
0x3dd895d7, 
0xad678846, 
0xdd0d7cc9, 
0x5768b525, 
0x29d9c998, 
Oxb7bd5c3b, 
0x74b1d29a, 
0xe3630b12, 
0x9309f f9d, 
0x1e01f268, 
0x6e6b06e7, 
Oxf9b9df6f, 
0xa1d1937e, 
Ox3fb506dd, 
0x41047a60, 
Oxcb61b38c, 
0xbb0b4703, 
0x2bb45a92, 
Ox5bdeaeld, 
0x9c0906a9, 
0xe2b87a14, 
0x7cdcefb7, 
0x1fda836e, 
0x88085ae6, 
Oxf862ae69, 
0x4e048354, 
0x3e6e77db, 
0xa9bcae53, 
Oxcabac28a, 
0x54de5729, 
0x2a6f2b94, 


void build_table() 


1 

ub4 i, j; 

for ( 
j =i; 
j = (j>>1 
j = (j>>1 
j = (j>>1 
j = (j>>1 


1=0; 1<256; ++i) 4 


^ 
^ 
^ 
^ 


“Y Y coc 


0x5f058808, 
0xc1611dab, 
Oxefd5102a, 
0x7807c9a2, 
0x086d3d2d, 
0x856530d8, 
Oxf50fc457, 
0x62dd1ddf, 
0x3ab551ce, 
0xa4d1c46d, 
0xda60b8d0, 
0x5005713c, 
0x206f85b3, 
0xb0d09822, 
OxcOba6cad, 
0xead54739, 
0x94643b84, 
0x0a00ae27, 
0x6906c2fe, 
Oxfed41b76, 
Ox8ebeeff9, 
0x38d8c2c4, 
0x48b2364b, 
Oxdf60efc3, 
Oxbc66831a, 
0x220216b9, 
0x5cb36a04, 
0x9b64c2b0, 
0xeb0e363f, 
0x7bb12bae, 
OxObdbdf21, 
Ox81bel6cd, 
Oxff0f6a70, 
Ox616bffd3, 
0x3903b3c2, 
O0xaedi16a4a, 
Oxdebb9ec5, 
0x53b39330, 
0x23d967bf, 
0xb40bbe37, 


Oxedb88320 : 
Oxedb88320 : 
Oxedb88320 : 
Oxedb88320 : 


0xc60cd9b2, 
0xb6662d3d, 
0x71b18589, 
0x0f00f934, 
0x91646c97, 
0xf262004e, 
0x65b0d9c6, 
0x15da2d49, 
0xa3bc0074, 
Oxd3d6f4fb, 
0x44042d73, 
0x270241aa, 
0xb966d409, 
0xc7d7a8b4, 
Oxedb88320, 
0x9dd277af, 
0x0d6d6a3e, 
0x7d079eb1, 
0xf762575d, 
0x89d32be0, 
0x17b7be43, 
Ox4fdff252, 
0xd80d2bda, 
0xa867df55, 
0x256fd2a0, 
0x5505262f, 
Oxc2d7ffa7, 
0xec63f226, 
0x72076785, 
0x0cb61b38, 
0x86d3d2d4, 
Oxf6b9265b, 
0x66063bca, 
0x166ccf45, 
0xa7672661, 
0xd9d65adc, 
0x47b2cf7f, 
0x24b4a3a6, 
0xb3667a2e, 
Oxc30c8eal, 


© © © © 


Sn we se 


0xb10be924, 
0x76dc4190, 
Ox06b6b51f, 
0x9609a88e, 
0xe6635c01, 
0x6c0695ed, 
0x12b7e950, 
0x8cd37cf3, 
0xd4bb30e2, 
0x4369e96a, 
0x33031de5, 
Oxbe0b1010, 
Oxce6le49f, 
0x59b33d17, 
Ox9abfb3b6, 
0x04db2615, 
Ox7aba5aa8, 
0xf00f9344, 
0x806567cb, 
0x10da7ab5a, 
0x60b08ed5, 
Oxd1bb67f1, 
Oxaf0alb4c, 
0x316e8eef, 
0x5268e236, 
Oxc5ba3bbe, 
Oxb5d0cf31, 
0x756aa39c, 
0x05005713, 
0x92d28e9b, 
0xf1d4e242, 
0x6fb077e1, 
0x11010b5c, 
0xa00ae278, 
0xd06016f7, 
0x40df0b66, 
Ox30b5ffe9, 
0xbad03605, 
0xc4614ab8, 
0x5a05dflb, 
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j = (j>>1) * ((j&1) ? 0xedb88320 : 0); 
j = (j>>1) * ((j&1) ? Oxedb88320 : 0); 
j = (j>>1) ^ ((j&1) ? 0xedb88320 : 0); 
j = (j>>1) * ((j&1) ? Oxedb88320 : 0); 
printf("0x%.8lx, ", j); 
if (i%6 == 5) printf("\n"); 

} 


/* the hash function */ 
ub4 crc(const void *key, ub4 len, ub4 hash) 
{ 
ub4 i; 
const ubl *k = key; 
for (hash=len, i=0; i<len; ++i) 
hash = (hash >> 8) ^ crctab[ (hash € Oxff) ^ k[ill; 
return hash; 


} 


/* To use, try "gcc -0 crc.c -o crc; crc < crc.c" */ 
int main() 


char s[1000]; 
while (gets(s)) printf("%.8lx\n", crc(s, strlen(s), 0)); 
return 0; 


} 


Nous sommes seulement intéressés par la fonction crc(). A propos, faites attention 
aux deux déclarations d'initialisation dans la boucle for() : hash=len, i=0. Le stan- 
dard C/C++ permet ceci, bien sür. Le code généré contiendra deux opérations dans 
la partie d'initialisation de la boucle, au lieu d'une. 


Compilons-le dans MSVC avec l'optimisation (/Ox). Dans un soucis de concision, 
seule la fonction crc() est listée ici, avec mes commentaires. 


_key$ = 8 ; size = 4 
_len$ = 12 ; size = 4 
_hash$ = 16 ; size = 4 
| crc PROC 
mov edx, DWORD PTR  len$[esp-4] 
xor ecx, ecx ; i est stocké dans ECX 
mov eax, edx 
test edx, edx 
jbe SHORT $LN1@crc 
push ebx 
push esi 
mov esi, DWORD PTR _key$[esp+4] ; ESI = key 
push edi 
$LL3@crc: 


; fonctionne avec des octets en utilisant seulement des registres 32-bit. 
; l'octet à l'adresse key+i est stocké dans EDI 
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movzx edi, BYTE PTR [ecx+esi] 
mov ebx, eax ; EBX = (hash = len) 
and ebx, 255 ; EBX hash € Oxff 


; XOR EDI, EBX (EDI-EDI^EBX) 

; cette opération utilise tous les 32 bits de chaque registre 

; mais les autres bits (8-31) sont toujours mis à 0, donc c'est OK 

; ils sont mis à 0 car, comme pour EDI, cela a été fait avec l'instruction 


MOVZX ci-dessus g 
; les bits hauts de EBX sont mis a 0 par l'instruction AND EBX, 255 ci-dessus 


(255 = Oxff) 
xor edi, ebx 


; EAX=EAX>>8; bits 24-31 pris de nul part seront mis à 0 
shr eax, 8 


; EAX=EAX*crctab[EDI*4] - choisir le EDI-éme élément de la table crctab[] 
xor eax, DWORD PTR crctab[edi*4] 


inc ecx ; ite 
cmp ecx, edx ; i«len ? 
jb SHORT $LL3QGcrc ; oui 
pop edi 
pop esi 
pop ebx 
$LNlecre: 
ret 0 
| crc ENDP 


Essayons la méme chose dans GCC 4.4.1 avec l'option -03 : 


public crc 
crc proc near 
key - dword ptr 8 
hash = dword ptr OCh 
push ebp 
xor edx, edx 
mov ebp, esp 
push esi 
mov esi, [ebp+key] 
push ebx 
mov ebx, [ebp+hash] 
test ebx, ebx 
mov eax, ebx 
jz short loc 80484D3 
nop ; remplissage 
lea esi, [esi+0] ; remplissage; fonctionne comme NOP 


; (ESI ne change pas ici) 


loc 80484B8: 
mov ecx, eax ; sauve l'état pérécédent du hash dans 
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ECX 


xor al, [esi+edx]; AL=*(key+i) 
add edx, 1 ; i++ 
shr ecx, 8 ; ECX=hash>>8 
movzx eax, al ; EAX=*(key+i) 
mov eax, dword ptr ds:crctab[eax*4] ; EAX-crctab[EAX] 
xor eax, ecx ; hash-EAX^ECX 
cmp ebx, edx 
ja short loc 80484B8 

loc 80484D3: 
pop ebx 
pop esi 
pop ebp 
retn 

crc endp 


GCC a aligné le début de la boucle sur une limite de 8-octet en ajoutant NOP et lea 
esi, [esi+0] (qui est aussi une opération sans effet). 


Vous pouvez en lire plus à ce sujet dans la section npad (.1.7 on page 1347). 


3.9 Exemple de calcul d'adresse réseau 


Comme nous le savons, une adresse (IPv4) consiste en quatre nombres dans l'inter- 
valle 0...255, i.e., quatre octets. 


Quatre octets peuvent étre stockés facilement dans une variable 32-bit, donc une 
adresse IPv4 d'hóte, de masque réseau ou d'adresse de réseau peuvent toutes étre 
un entier 32-bit. 


Du point de vue de l'utilisateur, le masque réseau est défini par quatre nombres 
et est formaté comme 255.255.255.0, mais les ingénieurs réseaux (sysadmins) uti- 
lisent une notation plus compacte comme «/8 », «/16 », etc. 


Cette notation défini simplement le nombre de bits qu'a le masque, en commencant 
par le MSB. 
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Masque | Hóte Utilisable | Masque de réseau | Masque hexadécimal 

/30 4 2 255.255.255.252 Oxfffffffc 

129 8 6 255.255.255.248 Oxfffffff8 

128 16 14 255.255.255.240 OxfffffffO 

127 32 30 255.255.255.224 OxffffffeO 

/26 64 62 255.255.255.192 OxffffffcO 

124 256 254 255.255.255.0 OxffffffOO réseau de classe C 
123 512 510 255.255.254.0 Oxfffffe00 

122 1024 1022 255.255.252.0 Oxfffffc00 

/21 2048 2046 255.255.248.0 Oxfffff800 

120 4096 4094 255.255.240.0 Oxfffff000 

/19 8192 8190 255.255.224.0 Oxffffe000 

/18 16384 16382 255.255.192.0 Oxffffc000 

/17 32768 32766 255.255.128.0 Oxffff8000 

/16 65536 65534 255.255.0.0 Oxffff0000 réseau de classe B 
18 16777216 | 16777214 | 255.0.0.0 Oxff000000 réseau de classe A 


Voici un petit exemple, qui calcule l'adresse du réseau en appliquant le masque 
réseau à l'adresse de l'hôte. 


#include <stdio.h> 
#include <stdint.h> 


uint32 t form IP (uint8 t ipl, uint8 t ip2, uint8 t ip3, uint8 t ip4) 
1 
return (ipl««24) | (ip2<<16) | (ip3««8) | ip4; 


}; 
void print as IP (uint32 t a) 
{ 
printf ("%d.%d.%d.%d\n", 
(a>>24)60xFF, 
(a>>16) &OxFF, 
(a>>8)80xFF, 
(a) &OxFF) ; 
}; 
// bit=31..0 
uint32 t set bit (uint32 t input, int bit) 
1 
return input=input| (1<<bit); 
}; 


uint32 t form netmask (uint8 t netmask bits) 
{ 

uint32 t netmask=0; 

uint8 t i; 


for (i20; i<netmask bits; i++) 
netmask=set_bit(netmask, 31-i); 


return netmask; 


WO U1 SUN) H 
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void calc network address (uint8 t ipl, uint8 t ip2, uint8 t ip3, uint8 t 7 
S ip4, uint8 t netmask bits) 


1 
uint32 t netmask=form netmask(netmask bits); 
uint32 t ip-form IP(ipl, ip2, ip3, ip4); 
uint32 t netw adr; 
printf ("netmaskz"); 
print as IP (netmask); 
netw adr-ip&netmask; 
printf ("network address=") ; 
print as IP (netw adr); 
$; 
int main() 
1 
calc network address (10, 1, 2, 4, 24); // 10.1.2.4, /24 
calc network address (10, 1, 2, 4, 8); // 10.1.2.4, /8 
calc network address (10, 1, 2, 4, 25); // 10.1.2.4, /25 
calc network address (10, 1, 2, 64, 26); // 10.1.2.4, /26 
$; 


3.9.1 calc_network_address() 


La fonction calc network address() est la plus simple: elle effectue simplement 
un AND entre l'adresse de l'hôte et le masque de réseau, dont le résultat est l'adresse 
du réseau. 


Listing 3.10 : MSVC 2012 avec optimisation /ObO 


_ip1$ = 8 ; size = 1 
_ip2$ = 12 ; size = 1 
_ip3$ = 16 ; size = 1 
_ip4$ = 20 ; size = 1 
_netmask_bits$ = 24 ; size = 1 
calc network address PROC 
push edi 
push DWORD PTR netmask bits$[esp] 
call form netmask 
push OFFSET $5G3045 ; 'netmask=' 
mov edi, eax 
call DWORD PTR imp printf 
push edi 
call print as IP 


push OFFSET $5G3046 ; ‘network address=' 
call DWORD PTR imp printf 

push DWORD PTR _ip4$[esp+16] 

push DWORD PTR _ip3$[esp+20] 

push DWORD PTR _ip2$[esp+24] 

push DWORD PTR _ipl$[esp+28] 

call form IP 
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and eax, edi ; network address = host address € netmask 
push eax 

call print as IP 

add esp, 36 

pop edi 

ret 0 


calc network address ENDP 


À la ligne 22, nous voyons le plus important AND—ici l'adresse du réseau est calculée. 


3.9.2 form IP() 


La fonction form IP() met juste les 4 octets dans une valeur 32-bit. 


Voici comment cela est fait habituellement: 


Allouer une variable pour la valeur de retour. La mettre à 0. 


Prendre le 4éme octet (de poids le plus faible), appliquer l'opération OR à cet 
octet et renvoyer la valeur. 


Prendre le troisiéme octet, le décaler à gauche de 8 bits. Vous obtenez une 
valeur comme 0x0000bb00 ou bb est votre troisiéme octet. Appliquer l'opération 
OR à la valeur résultante. La valeur de retour contenait 0x000000aa jusqu'à 
présent, donc effectuer un OU logique des valeurs produira une valeur comme 
0x0000bbaa. 


Prendre le second octet, le décaler à gauche de 16 bits. Vous obtenez une va- 
leur comme 0x00cc0000 ou cc est votre deuxiéme octet. Appliquer l'opération 
OR à la valeur résultante. La valeur de retour contenait 0x0000bbaa jusqu'à 
présent, donc effectuer un OU logique des valeurs produira une valeur comme 
0x00ccbbaa. 


Prendre le premier octet, le décaler à gauche de 24 bits. Vous obtenez une 
valeur comme 0xdd000000 où dd est votre premier octet. Appliquer l'opération 
OR à la valeur résultante. La valeur de retour contenait 0x00ccbbaa jusqu'à 
présent, donc effectuer un OU logique des valeurs produira une valeur comme 
Oxddccbbaa. 


Voici comment c’est fait par MSVC 2012 sans optimisation: 


Listing 3.11 : MSVC 2012 sans optimisation 


; désigner ipl comme "dd", ip2 comme "cc", ip3 comme "bb", ip4 comme "aa". 
_ip1$ = 8 ; taille = 1 
_ip2$ = 12 ; taille = 1 
_ip3$ = 16 ; taille = 1 
_ip4$ = 20 ; taille = 1 
_form IP PROC 
push ebp 
mov ebp, esp 


MOVZX eax, BYTE PTR _ipl$[ebp] 
; EAX=000000dd 
shl eax, 24 
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; EAX=dd000000 


movzx ecx, BYTE PTR _ip2$[ebp] 


; ECX=000000cc 


shl ecx, 16 


; ECX=00cc0000 


or eax, ecx 


; EAX=ddcc0000 


movzx edx, BYTE PTR _ip3$[ebp] 


; EDX=000000bb 
shl edx, 8 
; EDX=0000bb00 


or eax, edx 


; EAX=ddccbb00 


movzx ecx, BYTE PTR _ip4$[ebp] 


; ECX=000000aa 


or eax, ecx 
; EAX=ddccbbaa 
pop ebp 

ret 0 


form IP ENDP 


Certes, l'ordre est différent, mais, bien súr, l'ordre des opérations n'a pas d'impor- 


tance. 


MSVC 2012 avec optimisation produit en fait la méme chose, mais d'une facon dif- 


férente: 


Listing 3.12 : MSVC 2012 avec optimisation /ObO 


; désigner ipl comme "dd", ip2 comme "cc", ip3 comme "bb", ip4 comme "aa" 


_ipl$ = ; taille 
_ip2$ = 12 ; taille 
_ip3$ = 16 ; taille 
_ip4$ = 20 ; taille 


form IP PROC 


1 


I 
1 
1 


movzx eax, BYTE PTR _ipl$[esp-4] 


; EAX=000000dd 


movzx ecx, BYTE PTR _ip2$[esp-4] 


; ECX=000000cc 
shl eax, 8 
; EAX=0000dd00 


or eax, ecx 


; EAX=0000ddcc 


movzx ecx, BYTE PTR ip3$[esp-4] 


; ECX=000000bb 
shl eax, 8 
; EAX=00ddcc00 


or eax, ecx 


; EAX=00ddccbb 


movzx ecx, BYTE PTR _ip4$[esp-4] 


; ECX=000000aa 
shl eax, 8 
; EAX=ddccbb00 


or eax, ecx 
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; EAX=ddccbbaa 
ret 0 
form IP ENDP 


Nous pourrions dire que chaque octet est écrit dans les 8 bits inférieurs de la valeur 
de retour, et qu'elle est ensuite décalée à gauche d'un octet à chaque étape. 


Répéter 4 fois pour chaque octet en entrée. 
C'est tout! Malheureusement, il n'y sans doute pas d'autre moyen de le faite. 


Il n'y a pas de CPUs ou d'ISAs répandues qui possède une instruction pour composer 
une valeur à partir de bits ou d'octets. 


C'est d'habitude fait par décalage de bit et OU logique. 


3.9.3 print as IP() 
La fonction print as IP() effectue l'inverse: séparer une valeur 32-bit en 4 octets. 


Le découpage fonctionne un peu plus simplement: il suffit de décaler la valeur en 
entrée de 24, 16, 8 ou 0 bits, prendre les 8 bits d'indice O à 7 (octet de poids faible), 
et c'est fait: 


Listing 3.13 : MSVC 2012 sans optimisation 


_a$ = 8 ; size = 4 
_print as IP PROC 

push ebp 

mov ebp, esp 

mov eax, DWORD PTR a$[ebp] 

; EAX=ddccbbaa 

and eax, 255 

; EAX=000000aa 

push eax 

mov ecx, DWORD PTR _a$[ebp] 

; ECX=ddccbbaa 

shr ecx, 8 

; ECX=00ddccbb 

and ecx, 255 

; ECX=000000bb 

push ecx 

mov edx, DWORD PTR _a$[ebp] 

; EDX=ddccbbaa 

shr edx, 16 

; EDX=0000ddcc 

and edx, 255 

; EDX=000000cc 

push edx 

mov eax, DWORD PTR _a$[ebp] 

; EAX=ddccbbaa 

shr eax, 24 

; EAX=000000dd 

and eax, 255 ; sans doute une instruction redondante 


; EAX=000000dd 
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push eax 
push OFFSET $56G2973 ; ‘%d.%d.%d.%d' 
call DWORD PTR imp printf 


add esp, 20 
pop ebp 
ret 0 


print as IP ENDP 


MSVC 2012 avec optimisation fait presque la méme chose, mais sans recharger in- 
utilement la valeur en entrée: 


Listing 3.14 : MSVC 2012 avec optimisation /ObO 


_a$ = 8 ; size = 4 
print as IP PROC 
mov ecx, DWORD PTR a$[esp-4] 
; ECX=ddccbbaa 
movzx eax, cl 
; EAX=000000aa 


push eax 

mov eax, ecx 
; EAX=ddccbbaa 
shr eax, 8 

; EAX=00ddccbb 
and eax, 255 
; EAX=000000bb 
push eax 

mov eax, ecx 
; EAX=ddccbbaa 
shr eax, 16 
; EAX=0000ddcc 
and eax, 255 
; EAX=000000cc 
push eax 

; ECX=ddccbbaa 
shr ecx, 24 
; ECX=000000dd 
push ecx 


push OFFSET $56G3020 ; ‘%d.%d.%d.%d' 
call DWORD PTR imp printf 
add esp, 20 
ret 0 
print as IP ENDP 


3.9.4 form netmask() et set bit() 


La fonction form netmask() produit un masque de réseau à partir de la notation 
CIDR®. Bien súr, il serait plus efficace d'utiliser une sorte de table pré-calculée, mais 
nous utilisons cette facon de faire intentionnellement, afin d'illustrer les décalages 
de bit. 
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Nous allons aussi écrire une fonction séparées set bit(). Ce n'est pas une très 
bonne idée de créer un fonction pour une telle opération primitive, mais cela facilite 
la compréhension du fonctionnement. 


Listing 3.15 : MSVC 2012 avec optimisation /ObO 


_input$ = 8 ; size = 4 
_bit$ = 12 ; size = 4 
_set bit PROC 

mov ecx, DWORD PTR bit$[esp-4] 

mov eax, 1 

shl eax, cl 

or eax, DWORD PTR _input$[esp-4] 

ret 0 
_set bit ENDP 
_netmask_bits$ = 8 ; size = 1 
_form netmask PROC 

push ebx 

push esi 

movzx esi, BYTE PTR netmask bits$[esp+4] 

xor ecx, ecx 

xor bl, bl 

test esi, esi 

jte SHORT $LN9@form_netma 

xor edx, edx 
$LL3@form_netma: 

mov eax, 31 

sub eax, edx 

push eax 

push ecx 

call _set bit 

inc bl 

movzx edx, bl 

add esp, 8 

mov ecx, eax 

cmp edx, esi 

jl SHORT $LL3@form_netma 
$LN9@form_netma: 

pop esi 

mov eax, ecx 

pop ebx 

ret 0 


_form_netmask ENDP 


set bit() est primitive: elle décale juste 1 à gauche du nombre de bits dont nous 
avons besoin et puis effectue un OU logique avec la valeur «input». form netmask() 
a une boucle: elle met autant de bits (en partant du MSB) que demandé dans l'argu- 
ment netmask bits. 


3.9.5 Résumé 


C'est tout! Nous le lancons et obtenons: 
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netmask=255.255.255.0 
network address=10.1.2.0 
netmask=255.0.0.0 

network address=10.0.0.0 
netmask=255.255.255.128 
network address=10.1.2.0 
netmask=255.255.255.192 
network address=10.1.2.64 


3.10 Boucles: quelques itérateurs 


Dans la plupart des cas, les boucles ont un seul itérateur, mais elles peuvent en 
avoir plusieurs dans le code résultant. 


Voici un exemple trés simple: 


#include <stdio.h> 


void f(int *al, int *a2, size t cnt) 


{ 
size t i; 
// copier d'un tableau a l'autre selon un schema bizarre 
for (i=0; i<cnt; i++) 
al[i*3]=a2[i*7]; 
$; 


Il y a deux multiplications à chaque itération et ce sont des opérations coûteuses. 
Est-ce que ca peut étre optimisé d'une certaine facon? 


Oui, si l'on remarque que les deux indices de tableau prennent des valeurs qui 
peuvent étre facilement calculées sans multiplication. 


3.10.1 Trois itérateurs 


Listing 3.16 : MSVC 2013 x64 avec optimisation 


f PROC 

; RCX=al 

; RDX=a2 

; R8=cnt 
test r8, r8 ; cnt==0? sortir si oui 
je SHORT $LN1@f 
npad 11 

$LL3Qf : 
mov eax, DWORD PTR [rdx] 
lea rcx, QWORD PTR [rcx+12] 
lea rdx, QWORD PTR [rdx+28] 
mov DWORD PTR [rcx-12], eax 


dec r8 
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jne SHORT $LL3@f 
$LN1Gf: 

ret 0 
f ENDP 


Maintenant il y a 3 itérateurs: la variable cnt et deux indices, qui sont incrémentés 
par 12 et 28 à chaque itération. Nous pouvons récrire ce code en C/C++ : 


#include <stdio.h> 


void f(int *al, int *a2, size t cnt) 


{ 
size t i; 
size t idx1=0; idx2=0; 
// copier d'un tableau a l'autre selon un schema bizarre 
for (i20; i«cnt; i++) 
1 
al[idx1]=a2[idx2]; 
idx1+=3; 
idx2+=7; 
}; 
}; 


Donc, au prix de la mise à jour de 3 itérateurs à chaque itération au lieu d'un, nous 
pouvons supprimer deux opérations de multiplication. 

3.10.2 Deux itérateurs 

GCC 4.9 fait encore mieux, en ne laissant que 2 itérateurs: 


Listing 3.17 : GCC 4.9 x64 avec optimisation 


; RDI=al 
; RSI=a2 
; RDX=cnt 
f: 
test rdx, rdx ; cnt==0? sortir si oui 
je .L1 
; calculer l'adresse du dernier élément dans "a2" et la laisser dans RDX 
lea rax, [0+rdx*4] 
; RAX=RDX*4=cnt*4 
sal rdx, 5 
; RDX=RDX<<5=cnt*32 
sub rdx, rax 
; RDX=RDX-RAX=cnt*32-cnt*4=cnt*28 
add rdx, rsi 
; RDX=RDX+RSI=a2+cnt*28 
.L3: 
mov eax, DWORD PTR [rsi] 
add rsi, 28 
add rdi, 12 


mov DWORD PTR [rdi-12], eax 
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cmp rsi, rdx 
jne .L3 

.L1: 
rep ret 


Il n'y a plus de variable counter : GCC en a conclu qu'elle n'étais pas nécessaire. 


Le dernier élément du tableau a2 est calculé avant le début de la boucle (ce qui est 
facile: cnt 7) et c'est ainsi que la boucle est arrétée: itérer jusqu'à ce que le second 
index atteignent cette valeur pré-calculée. 


Vous trouverez plus d'informations sur la multiplication en utilisant des décalages/ad- 
ditions/soustractions ici: 1.24.1 on page 279. 


Ce code peut étre récrit en C/C++ comme ceci: 


#include <stdio.h> 


void f(int *al, int *a2, size t cnt) 


{ 
size t idx1=0; idx2=0; 
size t last_idx2=cnt*7; 
// copier d'un tableau a l'autre selon un schema bizarre 
for (;;) 
1 
al[idx1]2a2[idx2]; 
idx1+=3; 
idx2+=7; 
if (idx2==last_idx2) 
break; 
H 
}; 


GCC (Linaro) 4.9 pour ARM64 fait la même chose, mais il pré-calcule le dernier index 
de a1 au lieu de a2, ce qui a bien sûr le méme effet: 


Listing 3.18 : GCC (Linaro) 4.9 ARM64 avec optimisation 


; X0-al 
; Xl=a2 
; X2=cnt 
f: 
cbz x2, .L1 ; cnt==0? sortir si oui 
; calculer le dernier élément du tableau "al" 
add x2, x2, x2, isl 1 
;OX22X24X2««12X24X2*2zX2*3 
mov x3, 0 
Isl x2, x2, 2 
; X2=X2<<2=X2*4=X2*3*4=X2*12 
.L3: 
ldr w4, [x1],28 ; charger en X1, ajouter 28 à X1 
(post-incrémentation) 
str w4, [x0,x3] ; stocker en X0+X3=a1+X3 


add x3, x3, 12 ; décaler X3 
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cmp x3, x2 ; fini? 
bne .L3 

.L1: 
ret 


GCC 4.4.5 pour MIPS fait la méme chose: 
Listing 3.19 : GCC 4.4.5 for MIPS avec optimisation (IDA) 


; $a0=al 
; $al=a2 
; $a2=cnt 
f: 
; sauter au code de vérification de la boucle: 
begz $a2, locret 24 
; initialiser le compteur (i) à 0: 
move $v0, $zero ; slot de délai de branchement, NOP 
loc 8: 
; charger le mot 32-bit en $al 
lw $a3, 0($al) 


incrémenter le compteur (i): 
addiu $v0, 1 
vérifier si terminé (comparer "i" dans $v0 et "cnt" dans $a2): 
sltu $vl, $vO, $a2 
stocker le mot 32-bit en $a0: 
SW $a3, 0($a0) 
ajouter 0x1C (28) a $al a chaque itération: 
addiu $al, Ox1C 
; sauter au corps de la boulce si i<cnt: 
bnez $v1, loc 8 
ajouter OxC (12) à $a0 à chaque itération: 
addiu $a0, OxC ; slot de délai de branchement 


locret 24: 
jr $ra 


or $at, $zero ; slot de délai de branchement, NOP 


3.10.3 Cas Intel C++ 2011 


Les optimisations du compilateur peuvent étre bizarre, mais néanmoins toujours 


correctes. Voici ce qu le compilateur Intel C++ 2011 effectue: 


Listing 3.20 : Intel C++ 2011 x64 avec optimisation 


f PROC 
; parameter 1: rcx = al 
; parameter 2: rdx = a2 


; parameter 3: r8 = cnt 
.B1.1:: 
test r8, r8 
jbe exit 
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.B1.3:: 


just_copy2:: 


; R8 = cnt 
; RDX a2 
; RCX 


.B1.8:: 


; Ra = cnt 


r8, 6 
just copy 


rcx, rdx 
.B1.5 


r10, r8 

r9, rcx 

r10, 5 

rax, QWORD PTR [r8*4] 
r9, rdx 

r10, rax 

r9, r10 

just copy2 


rdx, rcx 
just copy 


r9, rdx 

rax, QWORD PTR [r8*8] 

r9, rcx 

r10, QWORD PTR [rax+r8*4] 
r9, r10 

just copy 


rl0d, rl0d 
r9d, rod 
eax, eax 


rlid, DWORD PTR [rax+rdx] 
r10 

DWORD PTR [r9+rcx], rilld 
r9, 12 

rax, 28 

r10, r8 

.B1.8 

exit 


rlOd, rl0d 
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xor r9d, rod 
xor eax, eax 
.B1.11:: 
mov rlld, DWORD PTR [rax+rdx] 
inc r10 
mov DWORD PTR [r9+rcx], rlld 
add rg, 12 
add rax, 28 
cmp r10, r8 
jb .B1.11 
exit:: 
ret 


Tout d'abord, quelques décisions sont prises, puis une des routines est exécutée. 
Il semble qu'il teste si les tableaux se recoupent. 


C'est une facons trés connue d'optimiser les routines de copie de blocs de mémoire. 
Mais les routines de copie sont les méme! 


ca doit étre une erreur de l'optimiseur Intel C++, qui produit néanmoins un code 
fonctionnel. 


Nous prenons volontairement en compte de tels exemples dans ce livre, afin que 
lecteur comprenne que le ce que génére un compilateur est parfois bizarre mais 
toujours correct, car lorsque le compilateur a été testé, il a réussi les tests. 


3.11 Duff's device 


Le dispositif de Duff? est une boucle déroulée avec la possibilité d'y sauter au milieu. 
La boucle déroulée est implémentée en utilisant une déclaration switch() sans arrét. 
Nous allons utiliser ici une version légérement simplifiée du code original de Tom Duff. 
Disons que nous voulons écrire une fonction qui efface une zone en mémoire. On 
pourrait le faire avec une simple boucle, effacant octet par octet. C'est étonnement 
lent, puisque tous les ordinateurs modernes ont des bus mémoire bien plus large. 
Donc, la meilleure facon de faire est d'effacer des zones de mémoire en utilisant des 
blocs de 4 ou 8 octets. Comme nous allons travailler ici avec un exemple 64-bit, nous 
allons effacer la mémoire par bloc de 8 octets. Jusqu'ici, tout va bien. Mais qu'en est- 
il du reste? La routine de mise à zéro de la mémoire peut aussi étre appelée pour 
des zones de taille non multiple de 8. Voici l'algorithme: 


* calculer le nombre de bloc de 8 octets, les effacer en utilisant des accés mé- 
moire 8-octets (64-bit) ; 


* calculer la taille du reste, l'effacer en utilisant ces accés mémoire d'un octet. 


La seconde étape peut étre implémentée en utilisant une simple boucle. Mais implémentons- 
là avec une boucle déroulée: 


9? Wikipédia 


633 


#include <stdint.h> 
#include <stdio.h> 


void bzero(uint8 t* dst, size t count) 


{ 

int i; 

if (count&(~7) ) 
// traiter les blocs de 8 octets 
for (i=0; i<count>>3; i++) 
{ 

*(uint64 t*)dst=0; 
dst=dst+8; 

}; 

// traiter le rset 

switch(count & 7) 

{ 

case 7: *dst++ = 0; 

case 6: *dst++ = 0; 

case 5: *dst++ = 0; 

case 4: *dst++ = 0; 

case 3: *dst++ = 0; 

case 2: *dst++ = 0; 

case 1: *dst++ = 0; 

case 0: // ne rien faire 
break; 

} 

} 


Tout d'abord, comprenons comment le calcul est effectué. La taille de la zone mé- 
moire est passée comme une valeur 64-bit. Et cette valeur peut étre divisée en deux 
parties: 


BIBBIBBISI'SIS 


( «B » est le nombre de blocs de 8-bit et «S» est la longueur du reste en octets ). 


Lorsque nous divisons la taille de la zone de mémoire entrée, la valeur est juste 
décalée de 3 bits vers la droite. Mais pour calculer le reste nous pouvons simplement 
isoler les 3 bits les plus bas! Donc, le nombre de bloc de 8-octets est calculé comme 
count >> 3 et le reste comme count&7. Nous devons aussi savoir si nous allons exécuter 
la procédure 8-octets, donc nous devons vérifier si la valeur de count est plus grande 
que 7. Nous le faisons en mettant à zéro les 3 bits les plus faible et en comparant le 
résultat avec zéro, car tout ce dont nous avons besoin pour répondre à la question 
est la partie haute de count non nulle, Bien sür, ceci fonctionne car 8 est 2? et que 
diviser par des nombres de la forme 2" est facile. Ce n'est pas possible pour d'autres 
nombres. Il est difficile de dire si ces astuces valent la peine d'étre utilisées, car elles 
conduisent à du code difficile à lire. Toutefois, ces astuces sont trés populaires et un 
programmeur pratiquant, méme s'il/si elle ne va pas les utiliser, doit néanmoins 
les comprendre. Donc la premiére partie est simple: obtenir le nombre de blocs de 
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8-octets et écrire des valeurs 64-bits zéro en mémoire La seconde partie est une 
boucle déroulée implémentée avec une déclaration switch() sans arrét. 


Premiérement, exprimons en francais ce que nous faisons ici. 


Nous devons «écrire autant d'octets à zéro en mémoire, que la valeur count&7 nous 
l'indique ». Si c'est O, sauter à la fin, et il n'y a rien à faire. Si c'est 1, sauter à l'en- 
droit à l'intérieur de la déclaration switch() oü une seule opération de stockage sera 
exécutée. Si c'est 2, sauter à un autre endroit, oü deux opérations de stockage se- 
ront exécutées, etc. Une valeur d'entrée de 7 conduit à l'exécution de toutes les 7 
opérations. I| n'y a pas de 8, car une zone mémoire de 8 octets serait traitée par 
la premiére partie de notre fonction. Donc, nous avons écrit une boucle déroulée. 
C'était assurément plus rapide sur les anciens ordinateurs que les boucles normales 
(et au contraire, les CPUs récents travaillent mieux avec des boucles courtes qu'avec 
des boucles déroulées). Peut-être est-ce encore utile sur les MCU!?s embarqués mo- 
derne à bas coût. 


Voyons ce que MSVC 2012 avec optimisation fait: 


dst$ = 8 
count$ - 16 
bzero PROC 
test rdx, -8 
je SHORT $LN11@bzero 
; traiter les blocs de 8 octets 
xor rlOd, rl0d 
mov r9, rdx 
shr r9, 3 
mov rad, rl0d 
test r9, r9 
je SHORT $LN11@bzero 
npad 5 
$LL19@bzero: 
inc r8d 
mov QWORD PTR [rcx], r10 
add rcx, 8 
movsxd rax, r8d 
cmp rax, r9 
jb SHORT $LL19@bzero 
$LN11@bzero: 
; traiter le reste 
and edx, 7 
dec rdx 
cmp rdx, 6 
ja SHORT $LN9@bzero 
lea r8, OFFSET FLAT: ImageBase 
mov eax, DWORD PTR $LN22@bzero[r8+rdx*4] 
add rax, r8 
jmp rax 
$LN8@bzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
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$LN7Gbzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
$LN6@bzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
$LN5Gbzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
$LN4@bzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
$LN3Gbzero: 
mov BYTE PTR [rcx], 0 
inc rcx 
$LN2Gbzero: 
mov BYTE PTR [rcx], 0 
$LN9Gbzero: 
fatret 0 
npad 1 
$LN22@bzero: 
DD $LN2@bzero 
DD $LN3@bzero 
DD $LN4@bzero 
DD $LN5@bzero 
DD $LN6@bzero 
DD $LN7@bzero 
DD $LN8@bzero 
bzero ENDP 


La premiéres partie de la fonction est prévisible. La seconde partie est juste une 
boucle déroulée et un saut y passant le contrôle du flux à la bonne instruction. Il 
n'y a pas d'autre code entre la paire d'instructions MOV/INC, donc l'exécution va 
continuer jusqu’a la fin, exécutant autant de paires d'instructions que nécessaire. A 
propos, nous pouvons observer que la paire d’instructions MOV/INC utilise un nombre 
fixe d'octets (3+3). Donc la paire utilise 6 octets. Sachant cela, mous pouvons nous 
passer de la table des sauts de switch(), nous pouvons simplement multiplier la 
valeur en entrée par 6 et sauter en current. RIP + input value * 6. 


Ceci peut aussi étre plus rapide car nous ne devons pas aller chercher une valeur 
dans la table des sauts. 


Il est possible que 6 ne soit pas une trés bonne constante pour une multiplication 
rapide et peut-être que ca n'en vaut pas la peine, mais vous voyez l'idée. 


C'est ce que les démomakers old-school faisaient dans le passé avec les boucles 
déroulées. 


11Comme exercice, vous pouvez essayer de retravailler le code pour se passer de la table des sauts. La 
paire d'instructions peut étre récrite de facon à ce qu'elle utilise 4 octets ou peut-étre 8. 1 octet est aussi 
possible (en utilisant l'instruction STOSB). 
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3.11.1 Faut-il utiliser des boucles déroulées? 


Les boucles déroulées peuvent étre bénéfiques si il n'y a pas de cache mémoire 
rapide entre la RAM et le CPU, et que le CPU, afin d'avoir le code de l'instruction 
suivante, doit le charger depuis la mémoire à chaque fois. C'est le cas des MCU 
low-cost moderne et des anciens CPUs. 


Les boucles déroulées sont plus lentes que les boucles courtes si il y a un cache 
rapide entre la RAM et le CPU, et que le corps de la boucle tient dans le cache, et 
que le CPU va charger le code depuis ce dernier sans toucher à la RAM. Les boucles 
rapides sont les boucles dont le corps tient dans le cache L1, mais des boucles encore 
plus rapide sont ces petites qui tiennent dans le cache des micro-opérations. 


3.12 Division par la multiplication 


Une fonction trés simple: 


int f(int a) 


1 

return a/9; 
}; 
3.12.1 x86 


...est compilée de manière trés prédictive: 


Listing 3.21 : MSVC 


_a$ = 8 ; taille = 4 
_f PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR a$[ebp] 
cdq ; extension du signe de EAX dans EDX:EAX 
mov ecx, 9 
idiv ecx 
pop ebp 
ret 0 
f ENDP 


IDIV divise le nombre 64-bit stocké dans la paire de registres EDX: EAX par la valeur 
dans ECX. Comme résultat, EAX contiendra le quotient, et EDX— le reste. Le résultat 
de la fonction f () est renvoyé dans le registre EAX, donc la valeur n'est pas déplacée 
après la division, elle est déjà à la bonne place. 


Puisque IDIV utilise la valeur dans la paire de registres EDX: EAX, l'instruction CDQ 
(avant IDIV) étend la valeur dans EAX en une valeur 64-bit, en tenant compte du 
signe, tout comme MOVSX le fait. 


Si nous mettons l'optimisation (/0x), nous obtenons: 
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Listing 3.22 : MSVC avec optimisation 


_a$ = 8 ; Size = 4 
f PROC 

mov ecx, DWORD PTR a$[esp-4] 
mov eax, 954437177 ; 38e38e39H 
imul ecx 
sar edx, 1 
mov eax, edx 
shr eax, 31 ; 0000001fH 
add eax, edx 
ret 0 

f ENDP 


Ceci est la division par la multiplication. L'opération de multiplication est bien plus 
rapide. Et il possible d'utiliser cette astuce *? pour produire du code effectivement 
équivalent et plus rapide. 


Ceci est aussi appelé «strength reduction » dans les optimisations du compilateur. 


GCC 4.4.1 génére presque le méme code, méme sans flag d'optimisation, tout comme 
MSVC avec l'optimisation: 


Listing 3.23 : GCC 4.4.1 sans optimisation 


public f 
f proc near 


arg 0 - dword ptr 8 


push ebp 
mov ebp, esp 
mov ecx, [ebp+arg 0] 
mov edx, 954437177 ; 38E38E39h 
mov eax, ecx 
imul edx 
sar edx, 1 
mov eax, ecx 
sar eax, 1Fh 
mov ecx, edx 
sub ecx, eax 
mov eax, ecx 
pop ebp 
retn 
f endp 


3.12.2 Comment ca marche 


Des mathématiques du niveau de l'école, nous pouvons nous souvenir que la division 
par 9 peut étre remplacée par la multiplication par i. En fait, parfois les compilateurs 
font cela pour l'arithmétique en virgule flottante, par exemple, l'instruction FDIV en 


12En savoir plus sur la division par la multiplication dans [Henry S. Warren, Hacker's Delight, (2002)10-3] 
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code x86 peut étre remplacée par FMUL. Au moins MSVC 6.0 va remplacer la division 
par 9 par un multiplication par 0.111111... et parfois il est difficile d'étre súr de quelle 
opération il s'agissait dans le code source. 


Mais lorsque nous opérons avec des valeurs entiéres et des registres CPU entier, 
nous ne pouvons pas utiliser de fractions. Toutefois, nous pouvons retravailler la 
fraction comme ceci: 


Et 24.1 24,1 MagicNumber 
result — 9-Tg—7 9.MagicN umber 


Avec le fait que la division par 2” est trés rapide (en utilisant des décalages), nous 
devons maintenant trouver quels MagicNumber, pour lesquels l'équation suivante 
sera vraie: 2" = 9. MagicNumber. 


La division par 2?? est quelque peu cachée: la partie basse 32-bit du produit dans 
EAX n'est pas utilisée (ignorée), seule la partie haute 32-bit du produit (dans EDX) 
est utilisée et ensuite décalée de 1 bit additionnel. 


Autrement dit, le code assembleur que nous venons de voir multiplie par CUT 


32+1 
ou divise par SET. Pour trouver le diviseur, nous avons juste à diviser le numéra- 
teur par le dénominateur. En utilisant Wolfram Alpha, nous obtenons 8.99999999.... 
comme résultat (qui est proche de 9). 


, 


En lire plus à ce sujet dans [Henry S. Warren, Hacker's Delight, (2002)10-3]. 


Beaucoup de gens manquent la division "cachée" par 2?? or 29, lorsque la partie 
basse 32-bit (ou la partie 64-bit) du produit n'est pas utilisée. C'est pourquoi la divi- 
sion par la multiplication est difficile à comprendre au début. 


Mathematical Recipes??a une autre explication. 


3.12.3 ARM 


Le processeur ARM, tout comme un autre processeur «pur» RISC n'a pas d'instruc- 
tion pour la division. Il manque aussi une simple instruction pour la multiplication 
avec une constante 32-bit (rappelez-vous qu'une constante 32-bit ne tient pas dans 
un opcode 32-bit). 


En utilisant de cette astuce intelligente (ou hack), il est possible d'effectuer la divi- 
sion en utilisant seulement trois instructions: addition, soustraction et décalages de 
bit (1.28 on page 392). 


Voici un exemple qui divise un nombre 32-bit par 10, tiré de [Advanced RISC Ma- 
chines Ltd, The ARM Cookbook, (1994)3.3 Division by a Constant]. La sortie est 
constituée du quotient et du reste. 


; prend l'argument dans al 

; renvoie le quotient dans al, le reste dans a2 

; on peut utiliser moins de cycles si seul le quotient ou le reste est requis 
SUB a2, al, #10 ; garde (x-10) pour plus tard 
SUB al, al, al, lsr #2 
ADD al, al, al, lsr #4 


l3https://math. recipes 
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ADD al, al, al, lsr #8 
ADD al, al, al, lsr #16 
MOV al, al, lsr #3 

ADD a3, al, al, asl #2 


SUBS a2, a2, a3, asl #1 ; calcule (x-10) - (x/10)*10 
ADDPL al, al, #1 ; fix-up quotient 
ADDMI a2, a2, £10 ; fix-up reste 


MOV pc, tr 


avec optimisation Xcode 4.6.3 (LLVM) (Mode ARM) 


. text:00002C58 39 1E 08 E3 E3 18 43 E3 MOV R1, 0x38E38E39 

. text:00002C60 10 F1 50 E7 SMMUL RO, RO, R1 

. text:00002C64 CO 10 AO El MOV R1, RO, ASR*1 

. text:00002C68 AO OF 81 EO ADD RO, R1, RO,LSR#31 
. text:00002C6C 1E FF 2F El BX LR 


Ce code est presque le méme que celui généré par MSVC avec optimisation et GCC. 
Il semble que LLVM utilise le méme algorithme pour générer des constantes. 


Le lecteur attentif pourrait se demander comment MOV écrit une valeur 32-bit dans 
un registre, alors que ceci n'est pas possible en mode ARM. 


C'est impossible, en effet, mais on voit qu'il y a 8 octets par instruction, au lieu des 
4 standards, en fait, ce sont deux instructions. 


La premiére instruction charge 0x8E39 dans les 16 bits bas du registre et la se- 
conde instruction est MOVT, qui charge 0x383E dans les 16 bits hauts du registre. IDA 
reconnaît de telles séquences, et par concision, il les réduit a une seule «pseudo- 
instruction ». 


L'instruction SMMUL (Signed Most Significant Word Multiply mot le plus significatif 

d'une multiplication signée), multiplie deux nombres, les traitant comme des nombres 
signés et laisse la partie 32-bit haute dans le registre RO, en ignorant la partie 32-bit 

basse du résultat. 


L'instruction «MOV R1, RO,ASRZI» est le décalage arithmétique à droite d'un bit. 
«ADD RO, R1, RO,LSRZ31» est RO = R1 + R0 >> 31 


Il n'y a pas d'instruction de décalage séparée en mode ARM. A la place, des instruc- 
tions comme (MOV, ADD, SUB, RSB)!^ peuvent avoir un suffixe, indiquant si le second 
argument doit étre décalé, et si oui, de quelle valeur et comment. ASR signifie Arith- 
metic Shift Right, LSR—Logical Shift Right. 


avec optimisation Xcode 4.6.3 (LLVM) (Mode Thumb-2) 


MOV R1, 0x38E38E39 
SMMUL . W RO, RO, R1 
ASRS R1, RO, #1 


14Ces instructions sont également appelées «instructions de traitement de données» 
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ADD.W RO, R1, RO,LSR#31 
BX LR 


Il y a dex instructions de décalage séparées en mode Thumb, et l'une d'elle est 
utilisée ici—ASRS (arithmetic shift right). 
sans optimisation Xcode 4.6.3 (LLVM) and Keil 6/2013 


LLVM sans optimisation ne génére pas le code que nous avons vu avant dans cette 
section, mais insère à la place un appel à la fonction de bibliothèque _ divsi3. 


À propos de Keil: il insère un appel à la fonction de bibliothèque _aeabi_idivmod 
dans tous les cas. 


3.12.4 MIPS 


Pour une raison quelconque, GCC 4.4.5 avec optimisation génére seulement une 
instruction de division: 


Listing 3.24 : avec optimisation GCC 4.4.5 (IDA) 


f? 

li $v0, 9 

bnez $v0, loc 10 

div $a0, $v0 ; slot de délai de branchement 

break  0x1C00 ; "break 7" en assembleur sortir et objdump 
loc 10: 

mflo $v0 

jr $ra 

or $at, $zero ; slot de délai de branchement, NOP 


Ici, nous voyons une nouvelle instruction: BREAK. Elle lève simplement une excep- 
tion. 


Dans ce cas, une exception est levée si le diviseur est zéro (il n'est pas possible de 
diviser par zéro dans les mathématiques conventionnelles). 


Mais GCC n'a probablement pas fait correctement le travail d'optimisation et n'a pas 
vu que $VO ne vaut jamais zéro. 


Donc le test est laissé ici. Donc, si $VO est zéro, BREAK est exécuté, signalant l'ex- 
ception à l'OS. 


Autrement, MFLO s'exécute, qui prend le résultat de la division depuis le registre LO 
et le copie dans $VO. 


À propos, comme on devrait le savoir, l'instruction MUL laisse les 32bits hauts du 
résultat dans le registre HI et les 32 bits bas dans le registre LO. 


DIV laisse le résultat dans le registre LO, et le reste dans le registre HI. 


Si nous modifions la déclaration en «a 96 9», l'instruction MFHI est utilisée au lieu 
de MFLO. 
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3.12.5 Exercice 


* http://challenges.re/27 


3.13 Conversion de chaîne en nombre (atoi()) 


Essayons de ré-implémenter la fonction C standard atoi(). 


3.13.1 Exemple simple 


Voici la maniére la plus simple possible de lire un nombre encodé en ASCII. 


C'est sujet aux erreurs: un caractére autre qu'un nombre conduit à un résultat incor- 
rect. 


#include <stdio.h> 


int my_atoi (char *s) 


{ 
int rt=0; 
while (*s) 
{ 
rt=rt*10 + (*s-'0'); 
Stt; 
y; 
return rt; 
}; 
int main() 
{ 
printf ("%d\n", my atoi ("1234")); 
printf ("%d\n", my atoi ("1234567890") ); 
}; 


Donc, tout ce que fait l'algorithme, c'est de lire les chiffres de gauche à droite. 
Le caractère ASCII zéro est soustrait de chaque chiffre. 


Les chiffres de «0» à «9» sont consécutifs dans la table ASCII, donc nous n'avons 
méme pas besoin de connaître la valeur exacte du caractère «0 ». 


Tout ce que nous avons besoin de savoir, c'est que «0 » moins «0 » vaut 0, «9 » moins 
«0 » vaut 9, et ainsi de suite. 


Soustraire «0 » de chaque caractère résulte en un nombre de 0 à 9 inclus. 
Tout autre caractére conduit à un résultat incorrect, bien sür! 


Chaque chiffre doit étre ajouté au résultat final (dans la variable «rt»), mais le résul- 
tat final est aussi multiplié par 10 à chaque chiffre. 
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Autrement dit, le résultat est décalé à gauche d'une position au format décimal à 
chaque itération. 


Le dernier chiffre est ajouté, mais il n'y a pas de décalage. 


MSVC 2013 x64 avec optimisation 


Listing 3.25 : MSVC 2013 x64 avec optimisation 


s$ = 8 
my atoi PROC 
; charger le premier caractére 
movzx r8d, BYTE PTR [rcx] 
; EAX est alloué pour la variable "rt" 
; qui vaut 0 au début 
xor eax, eax 
; est-ce que le premier caractére est un octet à zéro, i.e., fin de chaine? 
; Si oui, sortir 
test r8b, r8b 


je SHORT $LN9@my_atoi 
$LL2@my_atoi: 
lea edx, DWORD PTR [rax+rax*4] 


; EDX=RAX+RAX*4=rt+rt*4=rt*5 
movsx eax, r8b 
; EAXecaractére en entrée 
; charger le caractére suivant dans R8D 
movzx r8d, BYTE PTR [rcx+1] 
; décaler le pointeur dans RCX sur le caractére suivant: 
lea rcx, QWORD PTR [rcx+1] 
lea eax, DWORD PTR [rax+rdx*2] 
; EAX=RAX+RDX*2=caractére en entrée + rt*5*2=caractere en entrée + rt*10 
: chiffre correct en soustrayant 48 (0x30 ou '0') 
add eax, -48 ; ffffffffffffffdOH 
; est-ce que le dernier caractére était zéro? 
test r8b, r8b 
; sauter au début de la boucle si non 


jne SHORT $LL2(Gmy atoi 
$LN9@my_atoi: 
ret 0 


my atoi ENDP 


Un caractére peut-étre chargé à deux endroits: le premier caractére et tous les carac- 
téres subséquents. Ceci est arrangé de cette maniére afin de regrouper les boucles. 


Il n'y a pas d'instructions pour multiplier par 10, à la place, deux instructions LEA le 
font. 


Parfois, MSVC utilise l'instruction ADD avec une constante négative à la place d'un 
SUB. C'est le cas. 


C'est trés difficile de dire pourquoi c'est meilleur que SUB. Mais MSVC fait souvent 
ceci. 
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GCC 4.9.1 x64 avec optimisation 


GCC 4.9.1 avec optimisation est plus concis, mais il y a une instruction RET redon- 
dante à la fin. Une suffit. 


Listing 3.26 : GCC 4.9.1 x64 avec optimisation 


my atoi: 

; charger le caractére en entrée dans EDX 
movsx edx, BYTE PTR [rdi] 

; EAX est alloué pour la variable "rt" 
xor eax, eax 

; Sortir, si le caractére chargé est l'octet nul 
test dl, dl 
je .L4 

.L3: 
Lea eax, [rax+rax*4] 

; EAX=RAX*5=rt*5 

; décaler le pointeur sur le caractére suivant: 


add rdi, 1 
lea eax, [rdx-48+rax*2] 
; EAX=caractere en entrée - 48 + RAX*2 = caractere en entrée - '0' + rt*10 


; charger le caractére suivant: 
movsx edx, BYTE PTR [rdi] 

; sauter au début de la boucle, si le caractére chargé n'est pas l'octet nul 
test dl, dl 


.L4: 


avec optimisation Keil 6/2013 (Mode ARM) 


Listing 3.27 : avec optimisation Keil 6/2013 (Mode ARM) 


my atoi PROC 
; R1 contiendra le pointeur sur le caractére 


MOV rl,r0 
: RO contiendra la variable "rt" 
MOV ro ,#0 
B [L0.28| 
[L0.12| 
ADD r0,r0,r0,LSL #2 
; RO=RO+RO<<2=rt*5 
ADD r0,r2,r0,LSL #1 


; RO=caractére entré +rt*5<<1 = caractère entré + rt*10 
; corriger le tout en soustrayant '0' de rt: 
SUB r0,r0,*0x30 
; décaler le pointeur sur le caractére suivant: 
ADD rl,rl,£1 
|LO.28| 
; charger le caractère entré dans R2 
LDRB r2,[r1,40] 
; est-ce que c'est l'octet nul? si non, sauter au corps de la boucle. 
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CMP r2,#0 

BNE |LO.12| 
: sortir si octet nul. 
; la variable "rt" est encore dans le registre RO, prête à être utilisée dans 
; la fonction appelante 

BX lr 

ENDP 


avec optimisation Keil 6/2013 (Mode Thumb) 
Listing 3.28 : avec optimisation Keil 6/2013 (Mode Thumb) 


my atoi PROC 
; R1 est le pointeur sur le caractére en entrée 


MOVS rl,r0 
; RO est alloué pour la variable "rt" 
MOVS r0,#0 
B [L0.16| 
[L0.6| 
MOVS r3,#0xa 
; R3=10 
MULS r0,r3,r0 


; RO=R3*RO=rt*10 
; décaler le pointeur sur le caractére suivant: 


ADDS rl,rl1,71 
: corriger le tout en lui soustrayant le caractére '0': 
SUBS r0,r0,*0x30 
ADDS r0,r2,r0 
; rt=R2+R0=caractere entré + (rt*10 - '0') 
|LO.16| 
; charger le caractère entré dans R2 
LDRB r2,[r1,420] 
; est-ce zéro? 
CMP r2,#0 
; Sauter au corps de la boucle si non 
BNE |LO.6| 


; la variable rt est maintenant dans RO, préte a étre utilisé dans la 
fonction appelante 
BX lr 
ENDP 


De facon intéressante, nous pouvons nous rappeler des cours de mathématiques 
que l'ordre des opérations d'addition et de soustraction n'a pas d'importance. 


C'est notre cas: d'abord, l'expression rt + 10-' 0' est calculée, puis la valeur du carac- 
tére en entrée lui est ajoutée. 


En effet, le résultat est le méme, mais le compilateur a fait quelques regroupements. 


GCC 4.9.1 ARM64 avec optimisation 


Le compilateur ARM64 peut utiliser le suffixe de pré-incrémentation pour les instruc- 
tions: 
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Listing 3.29 : GCC 4.9.1 ARM64 avec optimisation 


my_atoi: 
; charger le caractére en entrée dans W1 
ldrb wl, [x0] 
mov x2, x0 
; X2=adresse de la chaíne en entrée 
; est-ce que le caractére chargé est zéro? 
: sauter à la sortie si oui 
: W1 contiendra 0 dans ce cas 
; il sera rechargé dans WO en L4. 
cbz wl, .L4 
; WO contiendra la variable "rt" 
; initialisons-la à zéro 
mov w0, 0 
.L3: 
; soustraire 48 ou '0' de la variable en entrée et mettre le résultat dans 


W3: 
sub w3, wl, #48 


; charger le caractère suivant à l'adresse X241 dans W1 avec 
pré-incrémentation: 
ldrb wl, [x2,1]! 
add w0, w0, wO, lsl 2 
; WO=W0+W0<<2=W0+W0*4=rt*5 
add w0, w3, w0, lsl 1 
; WO-chiffre entrée + WO<<1 = chiffre entrée + rt*5*2 = chiffre entrée + 


rt*10 
; Si le caractére que nous venons de charger n'est pas l'octet nul, 


; sauter au début de la boucle 
cbnz wl, .L3 
; la variable qui doit étre retournée (rt) est dans WO, préte à étre utilisée 
; dans la fonction appelante 
ret 
.L4: 
mov w0, wl 
ret 


3.13.2 Un exemple légerement avancé 


Mon nouvel extrait de code est plus avancé, maintenant il teste le signe «moins » 
au premier caractére et renvoie une erreur si un caractére autre qu'un chiffre est 
trouvé dans la chaíne en entrée: 


#include <stdio.h> 


int my atoi (char *s) 


1 
int negative-0; 
int rt=0; 
if (*s=='-') 
1 


negative-1; 
S++; 
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}; 
while (*s) 
1 
if (*s«'0' || *s>'9') 
1 
printf ("Error! Unexpected char: ‘%c'\n", *s); 
exit(0); 
}; 
rt=rt*10 + (*s-'0'); 
Stt; 
}; 


if (negative) 
return -rt; 


return rt; 
K 
int main() 
{ 
printf ("%d\n", my_atoi ("1234")); 
printf ("%d\n", my_atoi ("1234567890")); 
printf ("%d\n", my atoi ("-1234")); 
printf ("%d\n", my_atoi ("-1234567890")); 
printf ("%d\n", my atoi ("-a1234567890")); // error 
}; 


GCC 4.9.1 x64 avec optimisation 


Listing 3.30 : GCC 4.9.1 x64 avec optimisation 


.LC0: 
.String "Error! Unexpected char: '%c'\n" 
my atoi: 
sub rsp, 8 
movsx edx, BYTE PTR [rdi] 
; tester si c'est le signe moins 
cmp dl, 45 ; '-' 
je . L22 
xor esi, esi 
test dl, dl 
je . L20 
.L10: 
; ESI=0 ici si il n'y avait pas de signe moins et 1 si il en avait un 


lea eax, [rdx-48] 
; tout caractére autre qu'un chiffre résultera en 
; un nombre non signé plus grand que 9 aprés 
; soustraction donc s'il ne s'agit pas d'un chiffre, 
; sauter en L4, oü l'erreur doit étre rapportée 


cmp al, 9 
ja .L4 
xor eax, eax 
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jmp .L6 
L7: 
lea ecx, [rdx-48] 
cmp cl, 9 
ja .L4 
.L6: 
lea eax, [rax+rax*4] 
add rdi, 1 
lea eax, [rdx-48+rax*2] 


movsx edx, BYTE PTR [rdi] 

test dl, dl 

jne .L7 
; S'il n'y avait pas de signe moins, sauter l'instruction NEG 
; S'il y en avait un, l'exécuter. 


test esi, esi 
je .L18 
neg eax 
.L18: 
add rsp, 8 
ret 
.L22: 
movsx edx, BYTE PTR [rdi+1] 
lea rax, [rdi+1] 
test dl, dl 
je .L20 
mov rdi, rax 
mov esi, 1 
jmp .L10 
.L20: 
xor eax, eax 
jmp .L18 
.L4: 
; Signale une erreur. le caractére est dans EDX 
mov edi, 1 
mov esi, OFFSET FLAT:.LCO ; "Error! Unexpected char: '%c'\n" 
xor eax, eax 
call . printf chk 
xor edi, edi 
call exit 


Si le signe «moins» a été rencontré au début de la chaîne, l'instruction NEG est 
exécutée à la fin. Elle rend le nombre négatif. 


Il y a encore une chose à mentionner. 


Comment ferait un programmeur moyen pour tester si le caractére n'est pas un 
chiffre? Tout comme nous l'avons dans le code source: 


if (*s<'0' || *s>'9') 


Il y a deux opérations de comparaison. 


(D C0 -4 OY Ul UNA 


648 
Ce qui est intéressant, c'est que l'on peut remplacer les deux opérations par une 
seule: simplement soustraire «0 » de la valeur du caractére, 


traiter le résultat comme une valeur non-signée (ceci est important) et tester s'il est 
plus grand que 9. 


Par exemple, disons que l'entrée utilisateur contient le caractére point («.») qui a 
pour code ASCII 46. 46 - 48 = -2 si nous traitons le résultat comme un nombre signé. 


En effet, le caractére point est situé deux places avant le caractére «0 » dans la table 
ASCII. Mais il correspond à OxFFFFFFFE (4294967294) si nous traitons le résultat 
comme une valeur non signée, c'est définitivement plus grand que 9! 


Le compilateur fait cela souvent, donc il est important de connaitre ces astuces. 
Un autre exemple dans ce livre: 3.19.1 on page 688. 
MSVC 2013 x64 avec optimisation utilise les même astuces. 


avec optimisation Keil 6/2013 (Mode ARM) 


Listing 3.31 : avec optimisation Keil 6/2013 (Mode ARM) 


my atoi PROC 


PUSH {r4-r6, lr} 
MOV r4,r0 

LDRB r0, [r0, #0] 
MOV r6,#0 

MOV r5,r6 

CMP r0,#0x2d '-' 


; R6 contiendra 1 si le signe moins a été rencontré, 0 sinon 
MOVEQ r6,#1 
ADDEQ r4,r4,#1 


B |LO.80| 
[L0.36| 
SUB r0,r1,#0x30 
CMP r0,#0xa 
BCC [L0.64| 
ADR r0,|L0.220| 
BL __2printf 
MOV r0 ,#0 
BL exit 
[L0.64| 
LDRB ro,[r4],*1 
ADD rl,r5,r5,LSL #2 
ADD r0,r0,r1,LSL #1 
SUB r5,r0,#0x30 
[L0.80| 
LDRB rl, [r4,#0] 
CMP r1,#0 
BNE [L0.36| 
CMP r6,420 


; negate result 
RSBNE r0,r5,#0 
MOVEQ ro,r5 


33 
34 
35 
36 
37 
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POP {r4-r6,pc} 
ENDP 
|LO.220| 
DCB "Error! Unexpected char: '%c'in",0 


Il n'y a pas d'instruction NEG en ARM 32-bit, donc l'opération «Reverse Subtraction » 
(ligne 31) est utilisée ici. 


Elle est déclenchée si le résultat de l'instruction CMP (à la ligne 29) était «Not Equal» 
(non égal) (d'oü le suffixe -NE). 


Donc ce que fait RSBNE, c'est soustraire la valeur résultante de 0. 


Cela fonctionne comme l'opération de soustraction normale, mais échange les opé- 
randes 


Soustraire n'importe quel nombre de 0 donne sa négation: 0- x = -x. 
Le code en mode Thumb est en gros le méme. 
GCC 4.9 pour ARM64 peut utiliser l'instruction NEG, qui est disponible en ARM64. 


3.13.3 Exercice 


Oh, à propos, les chercheurs en sécurité sont souvent confrontés à un comportement 
imprévisible de programme lorsqu'il traite des données incorrectes. 


Par exemple, lors du fuzzing. À titre d'exercice, vous pouvez essayer d'entrer des 
caractéres qui ne soient pas des chiffres et de voir ce qui se passe. 


Essayez d'expliquer ce qui s'est passé, et pourquoi. 


3.14 Fonctions inline 


Le code inline, c'est lorsque le compilateur, au lieu de mettre une instruction d'appel 
à une petite ou à une minuscule fonction, copie son corps à la place. 


Listing 3.32 : Un exemple simple 


#include <stdio.h> 


int celsius to fahrenheit (int celsius) 


{ 
}; 


return celsius * 9 / 5 + 32; 


int main(int argc, char *argv[]) 
{ 
int celsius=atol(argv[1]); 
printf ("%d\n", celsius to fahrenheit (celsius) ); 
}; 


650 
...est compilée de facon trés prédictive, toutefois, si nous utilisons l'option d'optimi- 
sation de GCC (-03), nous voyons: 


Listing 3.33 : GCC 4.8.1 avec optimisation 


main: 
push ebp 
mov ebp, esp 
and esp, -16 
sub esp, 16 
call |. main 
mov eax, DWORD PTR [ebp+12] 
mov eax, DWORD PTR [eax+4] 
mov DWORD PTR [esp], eax 
call  atol 
mov edx, 1717986919 
mov DWORD PTR [esp], OFFSET FLAT:LC2 ; "%d\n" 
lea ecx, [eax+eax*8] 
mov eax, ecx 
imul edx 
sar ecx, 31 
sar edx 
sub edx, ecx 
add edx, 32 
mov DWORD PTR [esp+4], edx 
call _printf 
leave 
ret 


(Ici la division est effectuée avec une multiplication(3.12 on page 636).) 


Oui, notre petite fonction celsius to fahrenheit() a été placée juste avant l'appel 
à printf(). 


Pourquoi? C'est plus rapide que d'exécuter la code de cette fonction plus le surcoüt 
de l'appel/retour. 


Les optimiseurs des compilateurs modernes choisissent de mettre en ligne les pe- 
tites fonctions automatiquement. Mais il est possible de forcer le compilateur à 
mettre en ligne automatiquement certaines fonctions, en les marquants avec le mot 
clef «inline » dans sa déclaration. 


3.14.1 Fonctions de chaines et de mémoire 


Une autre tactique courante d'optimisation automatique est la mise en ligne des 
fonctions de chaînes comme strcpy(), stremp(), strlen(), memset(), memcmp(), memc- 
py(), etc.. 


Parfois, c'est plus rapide que d'appeler une fonction séparée. 


Ce sont des patterns trés fréquents et il est hautement recommandé aux rétro- 
ingénieurs d'apprendre à les détecter automatiquement. 
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strcmp() 


Listing 3.34 : exemple strcmp() 


bool is bool (char *s) 


1 
if (strcmp (s, "true")==0) 
return true; 
if (strcmp (s, "false")==0) 
return false; 
assert(0); 
}; 
Listing 3.35 : avec optimisation GCC 4.8.1 
.LC0: 
.string "true" 
.LC1: 
.string "false" 
is bool: 
. LFBO: 
push edi 
mov ecx, 5 
push esi 
mov edi, OFFSET FLAT: .LCO 
sub esp, 20 
mov esi, DWORD PTR [esp+32] 
repz cmpsb 
je .L3 
mov esi, DWORD PTR [esp+32] 
mov ecx, 6 
mov edi, OFFSET FLAT: .LC1 
repz cmpsb 
seta cl 
setb dl 
xor eax, eax 
cmp cl, dl 
jne .L8 
add esp, 20 
pop esi 
pop edi 
ret 
.L8: 
mov DWORD PTR [esp], 0 
call assert 
add esp, 20 
pop esi 
pop edi 
ret 
.L3: 
add esp, 20 
mov eax, 1 


pop esi 


652 


pop edi 
ret 
Listing 3.36 : MSVC 2010 avec optimisation 

$5G3454 DB 'true', OOH 
$SG3456 DB 'false', OOH 
_s$ = 8 ; taille = 4 
?is bool@@YA NPAD@Z PROC ; is bool 

push esi 

mov esi, DWORD PTR s$[esp] 

mov ecx, OFFSET $SG3454 ; 'true' 

mov eax, esi 

npad 4 ; aligner le label suivant 
$LL6@is bool: 

mov dl, BYTE PTR [eax] 

cmp dl, BYTE PTR [ecx] 

jne SHORT $LN7Qis bool 

test dl, dl 

je SHORT $LN8@is_ bool 

mov dl, BYTE PTR [eax+1] 

cmp dl, BYTE PTR [ecx+1] 

jne SHORT $LN7Qis bool 

add eax, 2 

add ecx, 2 

test dl, dl 

jne SHORT $LL6@is_ bool 
$LN8Gis bool: 

xor eax, eax 


jmp 
$LN7@is bool: 
sbb 
sbb 
$LN9@is bool: 
test 
jne 


mov 
pop 


ret 
$LN2@is bool: 


mov 
mov 

$LL10@is bool 
mov 
cmp 
jne 
test 
je 
mov 
cmp 


SHORT $LN9Gis bool 


eax, eax 
eax, -1 


eax, eax 
SHORT $LN2@is_ bool 


al, 1 
esi 


0 


ecx, OFFSET $5G3456 ; 'false' 
eax, esi 

dl, BYTE PTR [eax] 

dl, BYTE PTR [ecx] 

SHORT $LN11Qis bool 

dl, dl 

SHORT $LN12Qis bool 

dl, BYTE PTR [eax+1] 

dl, BYTE PTR [ecx+1] 
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jne 
add 
add 
test 
jne 
$LN12@is bool: 
xor 


jmp 
$LN11@is bool: 
sbb 
sbb 
$LN13Gis bool: 
test 
jne 


xor 
pop 


ret 
$LN1@is_ bool: 


push 
push 
push 
call 
add 


pop 


ret 


SHORT $LN11Qis bool 
eax, 2 
ecx, 2 
dl, dl 
SHORT $LL10@is bool 


eax, eax 
SHORT $LN13@is_ bool 


eax, eax 
eax, -1 


eax, eax 
SHORT $LN1Gis bool 


al, al 
esi 


0 


11 

OFFSET $5G3458 

OFFSET $5G3459 

DWORD PTR _ imp  wassert 
esp, 12 

esi 


0 


?is bool@@YA NPADGZ ENDP ; is bool 


strlen() 


Listing 3.37 : exemple strlen() 


int strlen test(char *s1) 


{ 


return strlen(s1); 


}; 


Listing 3.38 : avec optimisation MSVC 2010 


_s1$ = 8 ; size 


= 4 


_Strlen test PROC 


mov 
lea 
$LL3Gstrlen tes: 
mov 
inc 
test 
jne 
sub 
ret 


eax, DWORD PTR si$[esp-4] 
edx, DWORD PTR [eax+1] 


cl, BYTE PTR [eax] 
eax 

cl, cl 

SHORT $LL3@strlen tes 
eax, edx 

0 
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| strten test ENDP 


strcpy() 


Listing 3.39 : exemple strcpy() 


void strcpy test(char *s1, char *outbuf) 


strcpy(outbuf, s1); 


}; 
Listing 3.40 : avec optimisation MSVC 2010 

_s1$ = 8 ; taille = 4 
_outbuf$ = 12 ; taille = 4 
_strcpy_ test PROC 

mov eax, DWORD PTR si$[esp-4] 

mov edx, DWORD PTR _outbuf$[esp-4] 

sub edx, eax 

npad 6 ; aligner le label suivant 
$LL3Gstrcpy tes: 

mov cl, BYTE PTR [eax] 

mov BYTE PTR [edx+eax], cl 

inc eax 

test cl, cl 

jne SHORT $LL3Gstrcpy tes 

ret 0 


 Strcpy test ENDP 


memset() 


Exemple#1 


Listing 3.41 : 32 bytes 


#include <stdio.h> 


void f(char *out) 


{ 
}; 


memset(out, 0, 32); 


De nombreux compilateurs ne génèrent pas un appel à memset() pour de petits 
blocs, mais insèrent plutôt un paquet de MOVs: 


Listing 3.42 : GCC 4.9.1 x64 avec optimisation 


mov QWORD PTR [rdi], 0 
mov QWORD PTR [rdi+8], 0 
mov QWORD PTR [rdi+16], 0 
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mov QWORD PTR [rdi+24], O 
ret 


Á propos, ca nous rappelle le déroulement de boucles: 1.22.1 on page 251. 


Exemple#2 


Listing 3.43 : 67 bytes 


#include <stdio.h> 


void f(char *out) 


{ 
}; 


memset(out, 0, 67); 


Lorsque la taille du bloc n'est pas un multiple de 4 ou 8, les compilateurs se com- 
portent différemment. 


Par exemple, MSVC 2012 continue à insérer des MOVs: 


Listing 3.44 : MSVC 2012 x64 avec optimisation 


out$ = 8 

f PROC 
xor eax, eax 
mov QWORD PTR [rcx], rax 
mov QWORD PTR [rcx+8], rax 
mov QWORD PTR [rcx+16], rax 
mov QWORD PTR [rcx+24], rax 
mov QWORD PTR [rcx+32], rax 
mov QWORD PTR [rcx+40], rax 
mov QWORD PTR [rcx+48], rax 
mov QWORD PTR [rcx+56], rax 
mov WORD PTR [rcx+64], ax 
mov BYTE PTR [rcx+66], al 
ret 0 

f ENDP 


tandis que GCC utilise REP STOSQ, en concluant que cela sera plus petit qu'un 
paquet de MOVs: 


Listing 3.45 : GCC 4.9.1 x64 avec optimisation 


f: 
mov QWORD PTR [rdi], 0 
mov QWORD PTR [rdi+59], O 
mov rcx, rdi 
lea rdi, [rdi+8] 
xor eax, eax 
and rdi, -8 
sub rcx, rdi 


add ecx, 67 
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shr ecx, 3 

rep stosq 

ret 
memcpy() 


Petits blocs 


La routine pour copier des blocs courts est souvent implémentée comme une sé- 
quence d'instructions MOV. 


Listing 3.46 : exemple memcpy() 


void memcpy 7(char *inbuf, char *outbuf) 


1 

memcpy (outbuf+10, inbuf, 7); 

Listing 3.47 : MSVC 2010 avec optimisation 

 inbuf$ - 8 ; size = 4 
_outbuf$ = 12 ; size = 4 
_memcpy_7 PROC 

mov ecx, DWORD PTR _inbuf$[esp-4] 

mov edx, DWORD PTR [ecx] 

mov eax, DWORD PTR _outbuf$[esp-4] 

mov DWORD PTR [eax+10], edx 

mov dx, WORD PTR [ecx+4] 

mov WORD PTR [eax+14], dx 

mov cl, BYTE PTR [ecx+6] 

mov BYTE PTR [eax+16], cl 

ret 0 
_memcpy_7 ENDP 

Listing 3.48 : GCC 4.8.1 avec optimisation 

memcpy 7: 

push ebx 

mov eax, DWORD PTR [esp+8] 

mov ecx, DWORD PTR [esp+12] 

mov ebx, DWORD PTR [eax] 

lea edx, [ecx+10] 

mov DWORD PTR [ecx+10], ebx 

movzx ecx, WORD PTR [eax+4] 

mov WORD PTR [edx+4], cx 

movzx eax, BYTE PTR [eax+6] 

mov BYTE PTR [edx+6], al 

pop ebx 

ret 


C'est effectué en général ainsi: des blocs de 4-octets sont d'abord copiés, puis un 


mot de 16-bit (si nécessaire) et enfin un dernier octet (si nécessaire). 
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Les structures sont aussi copiées en utilisant MOV : 1.30.4 on page 466. 
Longs blocs 


Les compilateurs se comportent différemment dans ce cas. 


Listing 3.49 : memcpy() exemple 


void memcpy 128(char *inbuf, char *outbuf) 


{ 
memcpy(outbuf+10, inbuf, 128); 
}; 
void memcpy_123(char *inbuf, char *outbuf) 
{ 
memcpy(outbuf+10, inbuf, 123); 
}; 


Pour copier 128 octets, MSVC utilise une seule instruction MOVSD (car 128 est divisible 
par 4) : 


Listing 3.50 : MSVC 2010 avec optimisation 


_inbuf$ = 8 ; size = 4 
_outbuf$ = 12 ; size = 4 
 memcpy 128 PROC 
push esi 
mov esi, DWORD PTR inbuf$[esp] 
push edi 
mov edi, DWORD PTR _outbuf$[esp+4] 
add edi, 10 
mov ecx, 32 
rep movsd 
pop edi 
pop esi 
ret 0 


_memcpy_128 ENDP 


Lors de la copie de 123 octets, 30 mots de 32-bit sont tout d'abord copiés en utilisant 
MOVSD (ce qui fait 120 octets), puis 2 octets sont copiés en utilisant MOVSW, puis un 
autre octet en utilisant MOVSB. 


Listing 3.51 : MSVC 2010 avec optimisation 


_inbuf$ = 8 ; size = 4 
_outbuf$ = 12 ; size = 4 
_memcpy_123 PROC 
push esi 
mov esi, DWORD PTR _inbuf$[esp] 
push edi 
mov edi, DWORD PTR _outbuf$[esp+4] 
add edi, 10 


mov ecx, 30 
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_memcpy_123 ENDP 


rep movsd 
movsw 

movsb 

pop edi 
pop esi 
ret 0 


GCC utilise une grosse fonction universelle, qui fonctionne pour n'importe quelle 
taille de bloc: 


Listing 3.52 : GCC 4.8.1 avec optimisation 


memcpy 123: 
.LFB3: 
push edi 
mov eax, 123 
push esi 
mov edx, DWORD PTR [esp+16] 
mov esi, DWORD PTR [esp+12] 
lea edi, [edx+10] 
test edi, 1 
jne .L24 
test edi, 2 
jne .L25 
L7: 
mov ecx, eax 
xor edx, edx 
shr ecx, 2 
test al, 2 
rep movsd 
je .L8 
movzx edx, WORD PTR [esi] 
mov WORD PTR [edi], dx 
mov edx, 2 
.L8: 
test al, 1 
je .L5 
movzx eax, BYTE PTR [esi+edx] 
mov BYTE PTR [edi+edx], al 
«E52 
pop esi 
pop edi 
ret 
.L24: 
movzx eax, BYTE PTR [esi] 
lea edi, [edx+11] 
add esi, 1 
test edi, 2 
mov BYTE PTR [edx+10], al 
mov eax, 122 
je .L7 
.L25: 
movzx edx, WORD PTR [esi] 
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add edi, 2 

add esi, 2 

sub eax, 2 

mov WORD PTR [edi-2], dx 
jmp .L7 


.LFE3: 


Les fonctions de copie de mémoire universelles fonctionnent en général comme suit: 
calculer combien de mots de 32-bit peuvent étre copiés, puis les copier en utilisant 
MOVSD, et enfin copier les octets restants. 


Des fonctions de copie plus avancées et complexes utilisent les instructions SIMD et 
prennent aussi en compte l'alignement de la mémoire. 


Voici un exemple de fonction strlen() SIMD: 1.36.2 on page 539. 


memcmp() 


Listing 3.53 : exemple memcmp() 


int memcmp 1235(char *bufl, char *buf2) 
{ 


}; 


return memcmp(bufl, buf2, 1235); 


Pour n'importe quelle taille de bloc, MSVC 2013 insére la méme fonction universelle: 


Listing 3.54 : avec optimisation MSVC 2010 


_buf1$ = 8 ; size = 4 

_buf2$ = 12 ; size = 4 

 memcmp 1235 PROC 
mov ecx, DWORD PTR bufi$[esp-4] 
mov edx, DWORD PTR _buf2$[esp-4] 
push esi 
mov esi, 1231 
npad 2 

$LL5@memcmp_123: 
mov eax, DWORD PTR [ecx] 
cmp eax, DWORD PTR [edx] 
jne SHORT $LN4@memcmp_123 
add ecx, 4 
add edx, 4 
sub esi, 4 
jae SHORT $LL5@memcmp_123 

$LN4@memcmp_123: 
mov al, BYTE PTR [ecx] 
cmp al, BYTE PTR [edx] 
jne SHORT $LN6@memcmp_ 123 
mov al, BYTE PTR [ecx+1] 
cmp al, BYTE PTR [edx+1] 
jne SHORT $LN6@memcmp_123 
mov al, BYTE PTR [ecx+2] 


cmp al, BYTE PTR [edx+2] 
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jne SHORT $LN6Qmemcmp 123 
cmp esi, -1 
je SHORT $LN3@memcmp_123 
mov al, BYTE PTR [ecx+3] 
cmp al, BYTE PTR [edx+3] 
jne SHORT $LN6@memcmp_123 
$LN3QGmemcmp 123: 
xor eax, eax 
pop esi 
ret 0 
$LN6Gmemcmp 123: 
sbb eax, eax 
or eax, 1 
pop esi 
ret 0 


 memcmp 1235 ENDP 


strcat() 


Ceci est un strcat() inline tel qu'il a été généré par MSVC 6.0. Il y a 3 parties visibles: 
1) obtenir la longueur de la chaine source (premier scasb); 2) obtenir la longueur 
de la chaîne destination (second scasb); 3) copier la chaîne source dans la fin de la 
chaîne de destination (paire movsd/movsb). 


Listing 3.55 : strcat() 


lea edi, [src] 

or ecx, OFFFFFFFFh 
repne scasb 

not ecx 

sub edi, ecx 

mov esi, edi 

mov edi, [dst] 

mov edx, ecx 

or ecx, OFFFFFFFFh 
repne scasb 

mov ecx, edx 

dec edi 

shr ecx, 2 

rep movsd 

mov ecx, edx 

and ecx, 3 

rep movsb 


Script IDA 


Il y a aussi un petit script IDA pour chercher et suivre de tels morceaux de code inline, 
que l'on rencontre fréquemment: 


GitHub. 
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3.15 C99 restrict 


Voici une raison pour laquelle les programmes en Fortran, dans certains cas, fonc- 
tionnent plus vite que ceux en C/C++. 


void fl (int* x, int* y, int* sum, int* product, int* sum product, int* 7 
Vs update me, size t s) 


1 
for (int i-0; i<s; i++) 
1 
sum[i]-x[i]*y[i]; 
product[i]ex[i]*y[i]; 
update me[i]-i*123; // some dummy value 
sum product[i]-sum[i]-product[i]; 
}; 
}; 


C'est un exemple très simple, qui contient une spécificité: le pointeur sur le tableau 
update_me peut-être un pointeur sur le tableau sum, le tableau product ou même le 
tableau sum_product—rien ne l'interdit, n'est-ce pas? 


Le compilateur est parfaitement conscient de ceci, donc il génère du code avec 
quatre étapes dans le corps de la boucle: 


e calcule le sum[i] suivant 
* calcule le product[i] suivant 
* calcule le update me[i] suivant 


e calcule le sum product[i] suivant—à cette étape, nous devons charger depuis 
la mémoire les valeurs sum[i] et product[i] déjà calculées 


Et-il possible d'optimiser la derniére étape? Puisque nous avons déjà calculé sum[i] 
et product[i], il n'est pas nécessaire de les charger à nouveau depuis la mémoire. 


Oui, mais le compilateurs n'est pas sûr que rien n'a été récris à la 3ème étape! Ceci 
est appelé «pointer aliasing », une situation dans laquelle le compilateur ne peut pas 
étre sür que la mémoire sur laquelle le pointeur pointe n'a pas été modifiée. 


restrict dans le standard C99 [ISO/IEC 9899:TC3 (C C99 standard), (2007) 6.7.3/1] 
est une promesse faite par le programmeur au compilateur que les arguments de 
la fonction marqués par ce mot-clef vont toujours pointer vers des case mémoire 
différentes et ne vont jamais se recouper. 


Pour étre plus précis et décrire ceci formellement, restrict indique que seul ce poin- 
teur est utilisé pour accéder un objet, et qu'aucun autre pointeur ne sera utilisé pour 
ceci. 


On peut méme dire que l'objet ne sera accéder que par un seul pointeur, si il est 
marqué comme restrict. 


Ajoutons ce mot-clef à chaque argument pointeur: 


void f2 (int* restrict x, int* restrict y, int* restrict sum, int* restrict 
$ product, int* restrict sum product, 
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}; 


int* restrict update me, size t s) 


for (int i=0; i«s; i++) 


{ 


un 


sum[i]-ex[il*y[il; 
product[i]sex[i]*y[i]; 


update me[i]-i*123; // some dummy value 
sum product[i]-sum[i]-product[i]; 


Regardons le résultat: 


Listing 3.56 : GCC x64: f1() 


f1: 


.L6: 


.L4: 


.L1: 


push 
mov 
mov 
mov 
test 
je 
add 
xor 
mov 
xor 
jmp 


mov 
mov 


lea 
lea 
lea 
lea 
add 
mov 
add 
mov 
mov 
imul 
mov 
mov 
add 
mov 
add 
lea 
cmp 
mov 
jne 


pop 
ret 


r15 r14 r13 r12 rbp rdi rsi rbx 
r13, QWORD PTR 120[rsp] 
rbp, QWORD PTR 104[rsp] 
r12, QWORD PTR 112[rsp] 


r13, r13 
.L1 

r13, 1 
ebx, ebx 
edi, 1 
rlid, rlld 
.L4 

r11, rdi 
rdi, rax 


rax, 0[0+r11*4] 

r10, [rcx+rax] 

r14, [rdx+rax] 

rsi, [r8+rax] 

rax, r9 

r15d, DWORD PTR [r10] 

r15d, DWORD PTR [r14] 

DWORD PTR [rsi], rl5d ; 
r10d, DWORD PTR [r10] 

r10d, DWORD PTR [r14] 

DWORD PTR [rax], r10d ; 
DWORD PTR [r12+r11*4], ebx ; 
ebx, 123 

r10d, DWORD PTR [rsi] | 
r10d, DWORD PTR [rax] : 
rax, 1[rdi] 

rax, r13 

DWORD PTR O[rbp+r11*4], rl0d ; 
.L6 


rbx rsi rdi rbp r12 r13 r14 r15 


stocker dans sum[] 


stocker dans product[] 
stocker dans update me[] 
recharger sum[i] 
recharger product[i] 


stocker dans sum product[] 


663 


Listing 3.57 : GCC x64: f2() 


f2: 
push r13 r12 rbp rdi rsi rbx 
mov r13, QWORD PTR 104[rsp] 
mov rbp, QWORD PTR 88[rsp] 
mov r12, QWORD PTR 96[rsp] 
test r13, r13 
je .L7 
add r13, 1 
xor rlOd, rl0d 
mov edi, 1 
xor eax, eax 
jmp .L10 
.L11: 
mov rax, rdi 
mov rdi, r11 
.L10: 
mov esi, DWORD PTR [rcx+rax*4] 
mov r1ld, DWORD PTR [rdx+rax*4] 
mov DWORD PTR [rl2+rax*4], rl0d ; stocker dans update mel] 
add rlOd, 123 
lea ebx, [rsi+r11] 
imul rlld, esi 
mov DWORD PTR [r8+rax*4], ebx ; Stocker dans sum[] 
mov DWORD PTR [r9+rax*4], rlld ; Stocker dans product[] 
add rlld, ebx 
mov DWORD PTR O[rbp+rax*4], rlld ; stocker dans sum product[] 
lea rll, 1[rdi] 
cmp r11, r13 
jne .L11 
L7: 
pop rbx rsi rdi rbp r12 r13 
ret 


La différence entre les fonctions f1() et f2() compilées est la suivante: dans f1(), 
sum[i] et product[i] sont rechargés au milieu de la boucle, et il n'y a rien de tel 
dans f2(), les valeurs déjà calculées sont utilisées, puisque nous avons «promis » 
au compilateur que rien ni personne ne changera les valeurs pendant l'exécution du 
corps de la boucle, donc il est «certain » qu'il n'y a pas besoin de recharger la valeur 
depuis la mémoire. 


Étonnamment, le second exemple est plus rapide. 


Mais que se passe-t-il si les pointeurs dans les arguments de la fonction se modifient 
d'une maniére ou d'une autre? 


Ceci est du ressort de la conscience du programmeur, et le résultat sera incorrect. 
Retournons au Fortran. 


Les compilateurs de ce langage traitent tous les pointeurs de cette facon, donc lors- 
qu'il n'est pas possible d'utiliser restrict en C, Fortran peut générer du code plus 
rapide dans ces cas. 
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A quel point est-ce pratique? 
Dans les cas oü le fonction travaille avec des gros blocs en mémoire. 
C'est le cas en algébre linéaire, par exemple. 


Les superordinateurs/HPC?? utilisent beaucoup d'algébre linéaire, c'est probable- 
ment pourquoi, 

traditionnellement, Fortran y est encore utilisé [Eugene Loh, The Ideal HPC Program- 
ming Language, (2010)]. 


Mais lorsque le nombre d'itérations n'est pas trés important, certainement, le gain 
en vitesse ne doit pas étre significatif. 


3.16 Fonction abs() sans branchement 


Retravaillons un exemple que nous avons vu avant 1.18.2 on page 185 et demandons- 
nous, est-il possible de faire une version sans branchement de la fonction en code 
x86? 


int my abs (int i) 
1 
if (i«0) 
return -i; 
else 
return i; 


}; 


Et la réponse est oui. 


3.16.1 GCC 4.9.1 x64 avec optimisation 


Nous pouvons le voir si nous compilons en utilisant GCC 4.9 avec optimisation: 


Listing 3.58 : GCC 4.9 x64 avec optimisation 


my_abs: 
mov edx, edi 
mov eax, edi 
sar edx, 31 


EDX contient ici OxFFFFFFFF si le signe de la valeur en entrée est moins 
EDX contient O si le signe de la valeur en entrée est plus (0 inclus) 
; les deux instructions suivantes ont un effet seulement si EDX contient 


OxFFFFFFFF 
; et aucun si EDX contient 0 
xor eax, edx 
sub eax, edx 
ret 


Voici comment ca fonctionne: 


Décaler arithmétiquement la valeur en entrée par 31. 
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Le décalage arithmétique implique l'extension du signe, donc si le MSB est 1, les 32 
bits seront tous remplis avec 1, ou avec 0 sinon. 


Autrement dit, l'instruction SAR REG, 31 donne OxFFFFFFFF si le signe était négatif 
et 0 s'il était positif. 


Aprés l'exécution de SAR, nous avons cette valeur dans EDX. 


Puis, si la valeur est OxFFFFFFFF (i.e., le signe est négatif), la valeur en entrée est 
inversée (car XOR REG, OxFFFFFFFF est en effet une opération qui inverse tous les 
bits). 


Puis, à nouveau, si la valeur est OxFFFFFFFF (i.e., le signe est négatif), 1 est ajouté 
au résultat final (car soustraire -1 d'une valeur revient à l'incrémenter). 


Inverser tous les bits et incrémenter est exactement la facon dont une valeur en 
complément à deux est multipliée par -1. 


Nous pouvons observer que les deux derniéres instructions font quelque chose si le 
signe de la valeur en entrée est négatif. 


Autrement (si le signe est positif) elles ne font rien du tout, laissant la valeur en 
entrée inchangée. 


L'algorithme est expliqué dans [Henry S. Warren, Hacker's Delight, (2002)2-4]. 


Il est difficile de dire comment a fait GCC, l'a-t-il déduit lui-méme ou un pattern 
correspondant parmi ceux connus? 


3.16.2 GCC 4.9 ARM64 avec optimisation 


GCC 4.9 pour ARM64 génére en gros la méme chose, il décide juste d'utiliser des 
registres 64-bit complets. 


Il y a moins d'instructions, car la valeur en entrée peut étre décalée en utilisant un 
suffixe d'instruction («asr») au lieu d'une instruction séparée. 


Listing 3.59 : GCC 4.9 ARM64 avec optimisation 


my abs: 
; étendre le signe de la valeur 32-bit en entrée dans le registre X0 64-bit: 
sxtw x0, wO 
eor x1, x0, x0, asr 63 
; X1=X0"(X0>>63) (le décalage est arithmétique) 
sub x0, x1, x0, asr 63 
; X0=X1- (X0>>63)=X0" (X0>>63) - (X0>>63) 
; (tous les décalages sont arithmétiques) 
ret 


3.17 Fonctions variadiques 


Les fonctions comme printf() et scanf() peuvent avoir un nombre variable d'ar- 
guments. Comment sont-ils accédés? 
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3.17.1 Calcul de la moyenne arithmétique 


Imaginons que nous voulions calculer la moyenne arithmétique, et que pour une 
raison quelconque, nous voulions passer toutes les valeurs comme arguments de la 
fonction. 


Mais il est impossible d'obtenir le nombre d'arguments dans une fonction variadique 
en C/C++, donc indiquons la valeur -1 comme terminateur. 


Utilisation de la macro va arg 


Il y a le fichier d'entéte standard stdarg.h qui défini des macros pour prendre en 
compte de tels arguments. 


Les fonctions printf() et scanf () l'utilisent aussi. 


#include <stdio.h> 
#include <stdarg.h> 


int arith_mean(int v, ...) 
{ 
va list args; 
int sum=v, count=1, i; 
va start(args, v); 


while(1) 
1 
i-va arg(args, int); 
if (i==-1) // terminateur 
break; 
sum=sum+i; 
count++; 
} 


va_end(args); 
return sum/count; 


}; 
int main() 
{ 
printf ("%d\n", arith mean (1, 2, 7, 10, 15, -1 /* terminateur */))2 
Go 
}; 


Le premier argument doit être traité comme un argument normal. 


Tous les autres arguments sont chargés en utilisant la macro va arg et ensuite ajou- 
tés. 


Qu'y a-t-il à l'intérieur? 


Convention d'appel cdecl 
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Listing 3.60 : MSVC 6.0 avec optimisation 


_v$ = 8 
_arith_mean PROC NEAR 


mov eax, DWORD PTR v$[esp-4] 
push esi 
mov esi, 1 
lea edx, DWORD PTR v$[esp] 
$L838: 
mov ecx, DWORD PTR [edx+4] 
add edx, 4 
l'argument suivant 
cmp ecx, -1 
je SHORT $L856 
add eax, ecx 
inc esi 
jmp SHORT $L838 
$L856: 
; calculer le quotient 
cdq 
idiv esi 
pop esi 
ret 0 


_arith_mean ENDP 


$SG851 DB 'Sd', OaH, 00H 
_main PROC NEAR 
push -1 
push 15 
push 10 
push 7 
push 2 
push 1 
call _arith_mean 
push eax 
push OFFSET FLAT:$SG851 ; '%d' 
call _printf 
add esp, 32 
ret 0 
main  ENDP 


, 


charger le ler argument dans sum 


count=1 


, 
; adresse du ler argument 


charger l'argument suivant 
décaler le pointeur sur 


est-ce -1? 

sortir si oui 

sum = sum + argument chargé 
count++ 


Les arguments, comme on le voit, sont passés a main() un par un. 


Le premier argument est poussé sur la pile locale en premier. 


La valeur terminale (-1) est poussée plus tard. 


La fonction arith_mean() prend la valeur du premier argument et le stocke dans la 


variable sum. 


Puis, elle met dans le registre EDX l'adresse du second argument, prend sa valeur, 
l'ajoute à sum, et fait cela dans une boucle infinie, jusqu'à ce que -1 soit trouvé. 
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Lorsqu'il est rencontré, la somme est divisée par le nombre de valeurs (en excluant 
-1) et le quotient est renvoyé. 


Donc, autrement dit, la fonction traite le morceau de pile comme un tableau de 
valeurs entiéres d'une longueur infinie. 


Maintenant nous pouvons comprendre pourquoi la convention d'appel cdec/ nous 
force à pousser le premier argument au moins sur la pile. 


Car sinon, il ne serait pas possible de trouver le premier argument, ou, pour les 
fonctions du genre de printf, il ne serait pas possible de trouver l'adresse de la chaíne 
de format. 


Convention d'appel basée sur les registres 


Le lecteur attentif pourrait demander, qu'en est-il de la convention d'appel oü les 
tous premiers arguments sont passés dans des registres? Regardons: 


Listing 3.61 : MSVC 2012 x64 avec optimisation 


$5G3013 DB '*d', OaH, OOH 
v$ = 8 
arith mean PROC 
mov DWORD PTR [rsp+8], ecx ; ler argument 
mov QWORD PTR [rsp+16], rdx ; 2nd argument 
mov QWORD PTR [rsp+24], r8 ; 3éme argument 
mov eax, ecx ; sum = ler argument 
lea rcx, QWORD PTR v$[rsp+8] ; pointeur sur le 2nd argument 
mov QWORD PTR [rsp+32], r9 ; 4éme argument 
mov edx, DWORD PTR [rcx] ; Charger le 2nd argument 
mov red, 1 ; count=1 
cmp edx, -1 ; est-ce que le 2nd argument est -1? 
je SHORT $LN8Garith mean ; Sortir si oui 
$LL3@arith mean: 
add eax, edx ; sum = sum + argument chargé 
mov edx, DWORD PTR [rcx+8] ; charger l'argument suivant 
lea rcx, QWORD PTR [rcx+8] ; décaler le pointeur pour pointer 
; sur l'argument aprés le suivant 
inc r8d ; count++ 
cmp edx, -1 ; est-ce que l'argument chargé est 
-1? 
EB jne SHORT $LL3@arith mean ; aller au début de la boucle si non 


$LN8Garith mean: 
; calculer le quotient 


cdq 
idiv r8d 
ret 0 


arith mean ENDP 


main PROC 
sub rsp, 56 
mov edx, 2 


mov DWORD PTR [rsp+40], -1 
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mov DWORD PTR [rsp+32], 15 
lea r9d, QWORD PTR [rdx+8] 
lea r8d, QWORD PTR [rdx+5] 
lea ecx, QWORD PTR [rdx-1] 
call arith_mean 
lea rcx, OFFSET FLAT: $SG3013 
mov edx, eax 
call printf 
xor eax, eax 
add rsp, 56 
ret 0 

main ENDP 


Nous voyons que les 4 premiers arguments sont passés dans des registres, et les 


deux autres—par la pile. 


La fonction arith mean() place d'abord ces 4 arguments dans le Shadow Space puis 
traite le Shadow Space et la pile derriére comme s'il s'agissait d'un tableau continu! 


Qu'en est-il de GCC? Les choses sont légérement plus maladroites ici, car maintenant 
la fonction est divisée en deux parties: la premiére partie sauve les registres dans 


la «zone rouge », traite cet espace, et la seconde partie traite la pile: 


Listing 3.62 : GCC 4.9.1 x64 avec optimisation 


arith mean: 
lea rax, [rsp+8] 
; sauver les 6 registrers en entrée dans 
; la red zone sur la pile locale 


mov QWORD PTR [rsp-40], rsi 
mov QWORD PTR [rsp-32], rdx 
mov QWORD PTR [rsp-16], r8 
mov QWORD PTR [rsp-24], rcx 
mov esi, 8 
mov QWORD PTR [rsp-64], rax 
lea rax, [rsp-48] 
mov QWORD PTR [rsp-8], r9 
mov DWORD PTR [rsp-72], 8 
lea rdx, [rsp+8] 
mov r8d, 1 
mov QWORD PTR [rsp-56], rax 
jmp .L5 

L7: 
; traiter les arguments sauvés 
lea rax, [rsp-48] 
mov ecx, esi 
add esi, 8 
add rcx, rax 
mov ecx, DWORD PTR [rcx] 
cmp ecx, -1 
je .L4 

.L8: 
add edi, ecx 
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; est-ce que le nombre d'arguments actuel est inférieur ou égal à 6? 


.L5: 
; décider, quelle partie traiter maintenant. 
cmp esi, 47 
jbe 
; traiter les arguments de la pile 
mov rcx, rdx 
add rdx, 8 
mov ecx, DWORD PTR [rcx] 
cmp ecx, -1 
jne .L8 
.L4: 
mov eax, edi 
cdq 
idiv r8d 
ret 
LCL: 
.string "%d\n" 
main: 
sub rsp, 8 
mov edx, 7 
mov esi, 2 
mov edi, 1 
mov rod, -1 
mov r8d, 15 
mov ecx, 10 
xor eax, eax 
call arith mean 
mov esi, OFFSET FLAT: .LC1 
mov edx, eax 
mov edi, 1 
xor eax, eax 
add rsp, 8 
jmp . printf chk 


.L7 ; non, traiter les arguments sauvegardés; 


À propos, un usage similaire du Shadow Space est aussi considéré ici: 6.1.8 on 


page 962. 


Utilisation du pointeur sur le premier argument de la fonction 


L'exemple peut étre récrit sans la macro va arg : 


#include <stdio.h> 


int arith_mean(int v, ...) 
{ 
int *i-&v; 
int sum-*i, count=1; 
i++; 
while(1) 


{ 
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if ((*i)==-1) // terminator 


break; 
sum=sum+(*i); 
count++; 
i++; 
} 
return sum/count; 
}; 
int main() 
{ 
printf ("sdin", arith mean (1, 2, 7, 10, 15, -1 /* terminator */)); 
// test: https://ww.wolframalpha.com/input/?i=mean(1,2,7,10,15) 
}; 


Autrement dit, si l'argument mis est un tableau de mots (32-bit ou 64-bit), nous 
devons juste énumérer les éléments du tableau en commençant par le premier. 


3.17.2 Cas de la fonction vprintf() 


De nombreux programmeurs définissent leur propre fonction de logging, qui prend 
une chaîne de format du type de celle de printf+une liste variable d'arguments. 


Un autre exemple répandu est la fonction die(), qui affiche un message et sort. 


Nous avons besoin d'un moyen de transmettre un nombre d'arguments inconnu et 
de les passer à la fonction printf(). Mais comment? 


À l'aide des fonctions avec un «v » dans le nom. 


Une d'entre elles est vprintf() : elle prend une chaine de format et un pointeur sur 
une variable du type va list: 


#include <stdlib.h> 
#include <stdarg.h> 


void die (const char * fmt, ...) 
{ 
va list va; 
va start (va, fmt); 


vprintf (fmt, va); 
exit(0); 
}; 


En examinant plus précisément, nous voyons que va list est un pointeur sur un 
tableau. Compilons: 


Listing 3.63 : MSVC 2010 avec optimisation 


_fmt$ = 8 
_die PROC 
; charger le ler argument (format-string) 
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mov ecx, DWORD PTR fmt$[esp-4] 
; obtenir un pointeur sur le 2nd argument 
lea eax, DWORD PTR fmt$[esp] 
push eax ; passer un pointeur 
push ecx 
call _vprintf 
add esp, 8 
push 0 
call _exit 
$LN3@die: 
int 3 
_die ENDP 


Nous voyons que tout ce que fait notre fonction est de prendre un pointeur sur les 
arguments et le passe a la fonction vprintf(), et que cette fonction le traite comme 


un tableau infini d’arguments! 


Listing 3.64 : MSVC 2012 x64 avec optimisation 


fmt$ = 48 
die PROC 
; sauver les 4 premiers arguments dans le Shadow Space 
mov QWORD PTR [rsp+8], rcx 
mov QWORD PTR [rsp+16], rdx 
mov QWORD PTR [rsp+24], r8 
mov QWORD PTR [rsp+32], r9 
sub rsp, 40 
lea rdx, QWORD PTR fmt$[rsp+8] ; passer un pointeur sur le ler 
argument 
; ici RCX pointe toujours sur le ler argument (format-string) de 
die() 


; donc vprintf() va prendre son argument dans RCX 
call vprintf 


xor ecx, ecx 
call exit 
int 3 

die ENDP 


3.17.3 Cas Pin 


Il est intéressant de noter que certaines fonctions du framework DBI** Pin prennent 


un nombre variable d'arguments: 


INS InsertPredicatedCall( 
ins, IPOINT BEFORE, (AFUNPTR)RecordMemRead, 
IARG INST PTR, 
IARG MEMORYOP EA, memOp, 
IARG END); 


( pinatrace.cpp ) 


Et voici comment la fonction INS InsertPredicatedCall() est déclarée: 


léDynamic Binary Instrumentation 
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extern VOID INS InsertPredicatedCall(INS ins, IPOINT ipoint, AFUNPTR funptr 
Ge id 


(pin client.PH) 


Ainsi, les constantes avec un nom débutant par IARG sont des sortes d'arguments 
pour la fonction, qui sont manipulés à l'intérieur de INS InsertPredicatedCall(). 
Vous pouvez passer autant d'arguments que vous en avez besoin. Certaines com- 
mandes ont des arguments additionnels, d'autres non. Liste compléte des argu- 
ments: https://software.intel.com/sites/landingpage/pintool/docs/58423/ 
Pin/html/group INST  ARGS.htmLl. Et il faut un moyen pour détecter la fin de la 
liste des arguments, donc la liste doit étre terminée par la constante IARG END, sans 
laquelle, la fonction essayerait de traiter les données indéterminées dans la pile lo- 
cale comme des arguments additionnels. 


Aussi, dans [Brian W. Kernighan, Rob Pike, Practice of Programming, (1999)] nous 
pouvons trouver un bel exemple de routines C/C++ trés similaires à pack/unpack?” 
en Python. 


3.17.4 Exploitation de chaine de format 


Il y a une erreur courante, celle d'écrire printf(string) au lieu de puts(string) 
ouprintf("%s", string).Sil'attaquant peut mettre son propre texte dans string, 
il peut planter le processus ou accéder aux variables de la pile locale. 


Regardons ceci: 


#include <stdio.h> 


int main() 

{ 
char *sl="hello"; 
char *s2="world"; 
char buf[128]; 


// do something mundane here 
strcpy (buf, sl); 

strcpy (buf, " "); 

strcpy (buf, s2); 


printf ("%s"); 
}; 


Veuillez noter que printf() n'a pas d'argument supplémentaire autre que la chaîne 
de format. 


Maintenant, imaginons que c'est l'attaquant qui a mis la chaîne %s dans le premier 
argument du dernier printf (). Je compile cet exemple en utilisant GCC 5.4.0 sous 
Ubuntu x86, et l'exécutable résultant affiche la chaine «world » s'il est exécuté! 


Vhttps://docs.python.org/3/library/struct.html 


674 
Si je compile avec l'optimisation, printf () affiche n'importe quoi, aussi—probablement, 
l'appel a strcpy() a été optimisé et/ou les variables locales également. De méme, le 
résultat pour du code x64 sera différent, pour différents compilateurs, OS, etc. 


Maintenant, disons que l'attaquant peut passer la chaîne suivante à l'appel de printf(): 
%X %x %x %X %x. Dans mon cas, la sortie est: «80485c6 b7751b48 1 0 80485c0 » (ce 
sont simplement des valeurs de la pile locale). Vous voyez, il y a les valeurs 1 et 0, 

et des pointeurs (le premier est probablement un pointeur sur la chaine «world »). 
Donc si l'attaquant passe la chaîne *ss %s %s %s %s, le processus va se planter, car 
printf() traite 1 et/ou 0 comme des pointeurs sur une chaíne, essaye de lire des 
caractéres et échoue. 


Encore pire, il pourrait y avoir sprintf (buf, string) dans le code, oü buf est un 
buffer dans la pile locale avec un taille de 1024 octets ou autre, l'attaquant pourrait 
préparer une chaîne de telle sorte que buf serait débordé, peut-être méme de facon 
à conduire à l'exécution de code. 


De nombreux logiciels bien connus et trés utilisés étaient (ou sont encore) vulné- 
rables: 


QuakeWorld went up, got to around 4000 users, then the master 
server exploded. 
(QuakeWorld est arrivé, monté à environ 4000 utilisateurs, puis le ser- 
veur master a explosé.) 

Disrupter and cohorts are working on more robust code now. 
(Les perturbateurs et cohortes travaillent maintenant sur un code plus 
robuste.) 

If anyone did it on purpose, how about letting us know... (It wasn't 
all the people that tried 96s as a name) 
(Si quelqu'un l'a fait exprés, pourquoi ne pas nous le faire savoir... (Ce 
n'est pas tout le monde qui a essayé %s comme nom)) 


(John Carmack's .plan file, 17-Dec-1996?!? ) 
De nos jours, tous les compilateurs dignes de ce nom avertissent à propos de ceci. 


Un autre probléme qui est moins connu, c'est l'argument %n de printf() : lorsque 
printf () l'atteint dans la chaîne de format, il écrit le nombre de caractères écrits jus- 
qu'ici dans l'argument correspondant: stackoverflow.com. Ainsi, un attaquant peut 
zapper les variables locales en passant plusieurs commandes %n dans la chaîne de 
format. 


3.18 Ajustement de chaînes 


Un traitement de chaîne trés courant est la suppression de certains caractères au 
début et/oü à la fin. 


18https://github.com/ESWAT/john- carmack- plan-archive/blob/33ae52fdba46aa0d1abfed6fc7598233748541c0/ 
by day/johnc plan 19961217.txt 
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Dans cet exemple, nous allons travailler avec une fonction qui supprime tous les 
caractères newline (CR*9/LF20) à la fin de la chaîne entrée: 


#include <stdio.h> 
#include <string.h> 


char* str_trim (char *s) 


{ 
char c; 
size t str_len; 
// fonctionne tant que \r ou \n se trouve en fin de la chaine 
// s'arréte si un autre caractére s'y trouve ou si la chaine est vide 
// (au début ou au cours de notre opération) 
for (str_len=strlen(s); str_len>0 && (c=s[str_len-1]); str_len--) 
1 
if (c=='\r' || c=='\n') 
s[str_len-1]=0; 
else 
break; 
h 
return s; 
}; 
int main() 
1 
// test 
// strdup() est utilisé pour copier du texte de chaine dans le 
segment de données, 
// car autrement ca va crasher sur Linux, 
// où les chaîne de texte sont allouées dans le segment de données 
constantes, 
// et n'est pas modifiable. 
printf ("[%s]\n", str trim (strdup(""))); 
printf ("[%s]\n", str trim (strdup("\n"))); 
printf ("[9s]Nn", str trim (strdup("\r"))); 
printf ("[9$s]Nn", str trim (strdup("\n\r"))); 
printf ("[%s]\n", str trim (strdup("\r\n"))); 
printf ("[%s]\n", str trim (strdup("testl\r\n"))); 
printf ("[%s]\n", str trim (strdup("test2\n\r"))); 
printf ("[%s]\n", str trim (strdup("test3\n\r\n\r"))); 
printf ("[%s]\n", str trim (strdup("test4\n"))); 
printf ("[%s]\n", str_trim (strdup("test5\r"))); 
printf ("[%s]\n", str trim (strdup("test6\r\r\r"))); 
i 


L'argument en entrée est toujours renvoyé en sortie, ceci est pratique lorsque vous 
voulez chainer les fonctions de traitement de chaine, comme c’est fait ici dans la 


fonction main(). 


19Carriage return (13 ou ‘\r’ en C/C++) 
201 ine feed (10 ou ^n' en C/C++) 
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La seconde partie de for() (str_len>0 && (c=s[str len-1])) est appelé le «short- 
circuit» en C/C++ et est tres pratique [Dennis Yurichev, C/C++ programming lan- 
guage notes1.3.8]. 


Les compilateurs C/C++ garantissent une séquence d'évaluation de gauche a droite. 


Donc, si la premiére clause est fausse apres l'évaluation, la seconde n'est pas éva- 
luée. 


3.18.1 x64: MSVC 2013 avec optimisation 


Listing 3.65 : MSVC 2013 x64 avec optimisation 


s:$ = 8 
str trim PROC 


; RCX est le premier argument de la fonction et il contient toujours un 
pointeur sur la chaîne 
mov rdx, rcx 
; ceci est la fonction strlen() inlined juste ici: 
; mettre RAX à OxFFFFFFFFFFFFFFFF (-1) 


or rax, -1 
$LL14@str trim: 
inc rax 
cmp BYTE PTR [rcx+rax], 0 
jne SHORT $LL14@str trim 
; est-ce que la chaine en entrée est de longueur zéro? alors sortir: 
test rax, rax 
je SHORT $LN15Gstr trim 
; RAX contient la longueur de la chaíne 
dec rcx 
; RCX = s-1 
mov r8d, 1 
add rcx, rax 
; RCX = s-1+strlen(s), i.e., ceci est l'adresse du dernier caractère de la 
chaîne 
sub r8, rdx 
; R8 = 1-s 


$LL6@str trim: 
; charger le dernier caractère de la chaîne: 
: sauter si son code est 13 ou 10: 

movzx eax, BYTE PTR [rcx] 


cmp al, 13 

je SHORT $LN2Gstr trim 
cmp al, 10 

jne SHORT $LN15Gstr trim 


$LN2Gstr trim: 

; le dernier caractére a un code de 13 ou 10 

; écrire zéro à cet endroit: 
mov BYTE PTR [rcx], 0 

; décrémenter l'adresse du dernier caractére, 

; donc il pointera sur le caractére précédent celui qui vient d'étre effacé: 
dec rcx 
lea rax, QWORD PTR [r8+rcx] 
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; RAX = 1 - s + adresse du dernier caractère courant 
; ainsi nous pouvons déterminer si nous avons atteint le premier caractére et 
; nous devons arréter, si c'est le cas 


test rax, rax 

jne SHORT $LL6Qstr trim 
$LN15Gstr trim: 

mov rax, rdx 

ret 0 


str trim ENDP 


Tout d'abord, MSVC a inliné le code la fonction strlen(), car il en a conclus que ceci 
était plus rapide que le strlen() habituel + le coút de l'appel et du retour. Ceci est 
appelé de l'inlining: 3.14 on page 649. 


La premiére instruction de strlen() mis en ligne est 
OR RAX, OxFFFFFFFFFFFFFFFF. 


MSVC utilise souvent OR au lieu de MOV RAX, OxFFFFFFFFFFFFFFFF, car l'opcode 
résultant est plus court. 


Et bien súr, c'est équivalent: tous les bits sont mis à 1, et un nombre avec tous les 
bits mis vaut -1 en complément à 2. 


On peut se demander pourquoi le nombre -1 est utilisé dans strlen(). À des fins 
d'optimisation, bien sür. Voici le code que MSVC a généré: 


Listing 3.66 : Inlined strlen() by MSVC 2013 x64 


; RCX = pointeur sur la chaíne en entrée 
; RAX = longueur actuelle de la chaîne 
or rax, -1 
label: 
inc rax 
cmp BYTE PTR [rcx+rax], 0 
jne SHORT label 


; RAX = longueur de la chaîne 


Essayez d'écrite plus court si vous voulez initialiser le compteur à 0! OK, essayons: 


Listing 3.67 : Our version of strlen() 


; RCX = pointeur sur la chaine en entrée 
; RAX = longueur actuelle de la chaîne 
xor rax, rax 
label: 
cmp byte ptr [rcx+rax], 0 
jz exit 
inc rax 
jmp label 
exit: 


; RAX = longueur de la chaîne 


Nous avons échoué. Nous devons utilisé une instruction JMP additionnelle! 
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Donc, ce que le compilateur de MSVC 2013 a fait, c'est de déplacer l'instruction INC 
avant le chargement du caractere courant. 


Si le premier caractére est 0, c'est OK, RAX contient 0 à ce moment, donc la longueur 
de la chaine est O. 


Le reste de cette fonction semble facile à comprendre. 


3.18.2 x64: GCC 4.9.1 sans optimisation 


str trim: 
push rbp 
mov rbp, rsp 
sub rsp, 32 
mov QWORD PTR [rbp-24], rdi 
; la premiére partie de for() commence ici 
mov rax, QWORD PTR [rbp-24] 
mov rdi, rax 
call strlen 
mov QWORD PTR [rbp-8], rax ; str len 
; la premiére partie de for() se termine ici 
jmp .L2 
; le corps de for() commence ici 
.L5: 
cmp BYTE PTR [rbp-9], 13 > c=='"\r'? 
je .L3 
cmp BYTE PTR [rbp-9], 10 ; c=='\n'? 
jne .L4 
.L3: 
mov rax, QWORD PTR [rbp-8] ; str len 
lea rdx, [rax-1] ; EDX=str_len-1 
mov rax, QWORD PTR [rbp-24] ; s 
add rax, rdx ; RAX=s+str len-1 
mov BYTE PTR [rax], 0 ; S[str len-1]-0 


; le corps de for() se termine ici 
; la troisiéme partie de for() commence ici 


sub QWORD PTR [rbp-8], 1 ; Str len-- 
; la troisiéme partie de for() se termine ici 
.L2 
; la deuxiéme partie de for() commence ici 
cmp QWORD PTR [rbp-8], 0 ; str_len==0? 
je .L4 ; alors sortir 
; tester la seconde clause, et charger "c" 
mov rax, QWORD PTR [rbp-8] ; RAX=str len 
lea rdx, [rax-1] ; RDX=str_len-1 
mov rax, QWORD PTR [rbp-24] ; RAX-s 
add rax, rdx ; RAX=s+str_len-1 
movzx eax, BYTE PTR [rax] ; AL-s[str len-1] 
mov BYTE PTR [rbp-9], al ; Stocker l caractére chargé dans 
: cmp BYTE PTR [rbp-9], 0 ; est-ce zéro? 
jne .L5 ; oui? alors sortir 


; la deuxiéme partie de for() se termine ici 
.L4: 
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; renvoyer "s" 
mov rax, QWORD PTR [rbp-24] 
leave 
ret 


Les commentaires ont été ajoutés par l'auteur du livre. 


Aprés l'exécution de strlen(), le contróle est passé au label L2, et ici deux clauses 
sont vérifiées, l'une aprés l'autre. 


La seconde ne sera jamais vérifiée, si la premiere (str len==0) est fausse (ceci est 
un «short-circuit» (court-circuit)). 


Maintenant regardons la forme courte de cette fonction: 
* Premiére partie de for() (appel à strlen()) 
* goto L2 
* [5: corps de for(). sauter à la fin, si besoin 
* troisiéme partie de for() (décrémenter str len) 


* L2: deuxième partie de for() : vérifier la première clause, puis la seconde. sauter 
au début du corps de la boucle ou sortir. 


* L4: // sortir 


* renvoyer s 


3.18.3 x64: GCC 4.9.1 avec optimisation 


str trim: 
push rbx 
mov rbx, rdi 
; RBX sera toujours "s" 
call strlen 
; tester si str len--0 et sortir si c'est la cas 
test rax, rax 
je .L9 
lea rdx, [rax-1] 


; RDX contiendra toujours la valeur str len-1, pas str len 

; donc RDX est plutót comme une variable sur l'index du buffer 
lea rsi, [rbx«rdx] ; RSI=s+str len-1 
movzx ecx, BYTE PTR [rsi] ; charger le caractére 
test cl, cl 


je .L9 ; sortir si c'est zéro 

cmp cl, 10 

je .L4 

cmp cl, 13 ; sortir si ce n'est ni 'An' ni ‘\r' 
jne .L9 


.L4: 
; ceci est une instruction bizarre, nous voulons RSI=s-1 ici. 
; c'est possible de l'obtenir avec MOV RSI, EBX / DEC RSI 
; mais ce sont deux instructions au lieu d'une 
sub rsi, rax 
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; RSI = s+str len-1-str len = s-1 
; la boucle principale commence 


.L12: 
test rdx, rdx 
; Stocker zéro à l'adresse s-1+str_len-1+1 = s-1+str len = s+str_len-1 
mov BYTE PTR [rsi+l+rdx], 0 
; tester si str len-1==0. sortir si oui. 
je .L9 
sub rdx, 1 ; équivalent à str len-- 


; charger le caractére suivant à l'adresse s+str_len-1 
movzx ecx, BYTE PTR [rbx+rdx] 


test cl, cl ; est-ce zéro? sortir si oui 
je .L9 
cmp cl, 10 ; est-ce '\n'? 
je .L12 
cmp cl, 13 ; est-ce '\r'? 
je .L12 

.L9: 

; renvoyer "s" 
mov rax, rbx 
pop rbx 
ret 


Maintenant, c'est plus complexe. 


Le code avant le début du corps de la boucle est exécuté une seule fois, mais il 
contient le test des caractéres CR/LF aussi! À quoi sert cette duplication du code? 


La facon courante d'implémenter la boucle principale est sans doute ceci: 
* (début de la boucle) tester la présence des caractéres CR/LF, décider 
* Stocker le caractére zéro 

Mais GCC a décidé d'inverser ces deux étapes. 


Bien sür, stocker le caractére zéro ne peut pas étre la premiére étape, donc un autre 
test est nécessaire: 


* traiter le premier caractére. matcher avec CR/LF, sortir si le caractére n'est pas 
CR/LF 


* (début de la boucle) stocker le caractére zéro 
* tester la présence des caractéres CR/LF, décider 
Maintenant la boucle principale est trés courte, ce qui est bon pourles derniers CPUs. 


Le code n'utilise pas la variable str len, mais str len-1. Donc c'est plus comme un 
index dans un buffer. 


Apparemment, GCC a remarqué que l'expression str len-1 est utilisée deux fois. 


Donc, c'est mieux d'allouer une variable qui contient toujours une valeur qui est plus 
petite que la longueur actuelle de la chaine de un, et la décrémente (ceci a le méme 
effet que de décrémenter la variable str len). 


681 


3.18.4 ARM64: GCC (Linaro) 4.9 sans optimisation 
Cette implémentation est simple: 


Listing 3.68 : GCC (Linaro) 4.9 sans optimisation 


str trim: 
stp x29, x30, [sp, -48]! 
add x29, sp, 0 
str x0, [x29,24] ; copier l'argument en entrée dans la pile 
locale 
x0, [x29,24] ; s 
bl strlen 
str x0, [x29,40] ; la variable str len est dans la pile locale 
b .L2 
; la boucle principale commence 
.L5: 
ldrb w0, [x29,39] 
; WO=c 
cmp w0, 13 ; est-ce 'Nr'? 
beq .L3 
ldrb w0, [x29,39] 
; WO=c 
cmp w0, 10 ; est-ce '\n'? 
bne .L4 ; sauter à la sortie si non 
.L3: 
ldr x0, [x29,40] 
; X0-str len 
sub x0, x0, #1 
; X0-str len-1 
ldr x1, [x29,24] 
; Xl=s 
add x0, x1, x0 
; X0-s«str len-1 
strb wzr, [x0] ; écrire l'octet à s+str len-1 
; décrémenter str len: 
ldr x0, [x29,40] 
; X0-str len 
sub x0, x0, #1 
; X0-str len-1 
str x0, [x29,40] 
; sauver X0 (or str len-1) dans la pile locale 
.L2: 


ldr x0, [x29,40] 
; Str len--0? 


cmp x0, xzr 
; sauter alors à la sortie 
beq .L4 
ldr x0, [x29,40] 
; X0-str len 
sub x0, x0, #1 
; X0-str len-1 
ldr x1, [x29,24] 


; Xl=s 
add x0, x1, x0 
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X0=s+str_len-1 

charger l'octet à l'adresse s+str len-1 dans WO 
ldrb w0, [x0] 
strb w0, [x29,39] ; stocker l'octet chargé dans "c" 
ldrb w0, [x29,39] ; le recharger 

est-ce l'octet zéro? 


cmp w0, wzr 
; sauter à la sortie, si c'est zéro ou en L5 sinon 
bne .L5 
.L4: 
; renvoyer s 
ldr x0, [x29,24] 
ldp x29, x30, [sp], 48 
ret 


3.18.5 ARM64: GCC (Linaro) 4.9 avec optimisation 


Ceci est une optimisation plus avancée. 
Le premier caractére est chargé au début, et comparé avec 10 (le caractére LF). 


Les caractéres sont ensuite chargés dans la boucle principale, pour les caractéres 
aprés le premier. 


Ceci est quelque peu similaire à l'exemple 3.18.3 on page 679. 


Listing 3.69 : GCC (Linaro) 4.9 avec optimisation 


str trim: 
stp x29, x30, [sp, -32]! 
add x29, sp, 0 
str x19, [sp,16] 
mov x19, x0 
; X19 contiendra toujours la valeur de "s" 
bl strlen 
; X0-str len 
cbz x0, .L9 ; sauter en L9 (sortir) si str len--0 
sub x1, x0, #1 
; X1=X0-1=str_len-1 
add x3, x19, x1 
; X3=X19+X1=s+str_len-1 
ldrb w2, [x19,x1] ; charger l'octet à l'adresse 


X19+X1=s+str_len-1 
W2=octet chargé 


cbz w2, .L9 ; est-ce zéro? sauter alors à la sortie 
cmp w2, 10 ; est-ce 'An'? 
bne .L15 
.L12: 
; corps de la boucle principale. Le caractére chargé est toujours 10 ou 13 à 
ce moment! 
sub X2, x1, x0 
; X2-X1-X0-str len-1-str len--1 
add x2, x3, x2 


; X2=X3+X2=s+str_len-1+(-1)=s+str_len-2 
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strb wzr, [x2,1] ; stocker l'octet zéro à l'adresse 
s+str_len-2+1=s+str_len-1 
cbz x1, .L9 ; str_len-1==0? sauter a la sortie si oui 
sub x1, x1, #1 ; str_len-- 
ldrb w2, [x19,x1] ; charger le caractére suivant à l'adresse 
X19+X1=s+str_len-1 
cmp w2, 10 ; est-ce '\n'? 
cbz w2, .L9 ; sauter à la sortie, si c'est zéro 
beq .L12 : 
sauter au début du corps de la boucle, si c'est '\n' 
.L15: 
cmp w2, 13 ; est-ce 'Nr'? 
beq .L12 ; oui, sauter au début du corps de la boucle 
.L9: 
; renvoyer "s" 
mov x0, x19 
ldr x19, [sp,16] 
ldp x29, x30, [sp], 32 
ret 


3.18.6 ARM: avec optimisation Keil 6/2013 (Mode ARM) 


À nouveau, le compilateur tire partie des instructions conditionnelles du mode ARM, 
donc le code est bien plus compact. 


Listing 3.70 : avec optimisation Keil 6/2013 (Mode ARM) 


str trim PROC 


PUSH {r4, lr} 
; RO=s 
MOV r4,r0 
; R4ss 
BL strlen ; strlen() prend la valeur de "s" dans RO 
; RO=str len 
MOV r3,*0 
; R3 contiendra toujours 0 
[L0.16| 
CMP r0,#0 ; str_len==0? 
ADDNE r2,r4,r0 ; (si str_len!=0) R2=R4+R0=s+str_len 


LDRBNE r1,[r2,4-1] ; (si str_len!=0) Rl=charger l'octet a 
l'adresse R2-1=s+str_len-1 


CMPNE r1,#0 ; (si str_len!=0) comparer l'octet chargé avec 

BEQ [L0.56| ; sauter à la sortie si str len--0 ou si 
l'octet chargé est 0 

CMP r1,40xd ; est-ce que l'octet chargé est '\r'? 


CMPNE r1,#0xa H 
(si l'octet chargé n'est pas '\r') est-ce '\r'? 
SUBEQ r0,r0,#1 ; 
(si l'octet chargé est 'Xr' ou '\n') RO-- ou str len-- 
STRBEQ r3,[r2,#-1] ; (si l'octet chargé est '\r' ou '\n') stocker 
R3 (zéero) a l'adresse R2-1=s+str_len-1 
BEQ [L0.16| ; 
sauter au début de a boucle si l'octet chargé était '\r' ou '\n' 
[L0.56| 


WO U1 UNA 
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; renvoyer "s" 


MOV ro,r4 
POP {r4,pc} 
ENDP 


3.18.7 ARM: avec optimisation Keil 6/2013 (Mode Thumb) 


Il y a moins d'instructions conditionnelles en mode Thumb, donc le code est plus 
simple. 


Mais il y a des choses vraiment étranges aux offsets 0x20 et Ox1F (lignes 22 et 23). 
Pourquoi diable le compilateur Keil a-t-il fait ca? Honnétement, c'est difficile de le 
dire. 


Ca doit étre une bizarrerie du processus d'optimisation de Keil. Néanmoins, le code 
fonctionne correctement 


Listing 3.71 : avec optimisation Keil 6/2013 (Mode Thumb) 


str_trim PROC 


PUSH {r4, lr} 
MOVS r4,r0 
; R4ss 
BL strlen ; strlen() prend la valeur de "s" dans RO 
; RO=str len 
MOVS r3,*0 
; R3 contiendra toujours 0 
B [L0.24| 
[L0.12| 
CMP r1,#0xd ; est-ce que l'octet chargé est '\r'? 
BEQ [L0.20| 
CMP r1,#0xa ; est-ce que l'octet chargé est '\n'? 
BNE [L0.38]| ; sauter à la sortie si non 
[L0.20| 
SUBS r0,r0,71 ; R0-- ou str len-- 
STRB r3,[r2,#0x1f] ; stocker 0 à l'adresse 
R2+0x1F=s+str_len-0x20+0x1F=s+str_len-1 
[L0.24| 
CMP r0 ,#0 ; str len==0? 
BEQ [L0.38| ; oui? sauter à la sortie 
ADDS r2,r4,r0 ; R2=R4+R0=s+str_len 
SUBS r2,r2,#0x20 ; R2=R2-0x20=s+str_len-0x20 
LDRB rl,[r2,40x1f] ; charger l'octet à l'adresse 
R2+0x1F=s+str len-0x20+0x1F=s+str len-1 dans R1 
CMP r1,#0 ; est-ce que l'octet chargé est 0? 
BNE [L0.12| ; sauter au début de la boucle, si ce n'est 
pas 0 
[L0.38| 
; renvoyer "s" 
MOVS ro,r4 
POP {r4,pc} 
ENDP 
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3.18.8 MIPS 


Listing 3.72 : GCC 4.4.5 avec optimisation (IDA) 


str_trim: 
; IDA n'a pas connaissance des noms des variables locales, nous les entrons 
manuellement 

saved GP = -0x10 

saved SO - -8 

saved RA = -4 
lui $gp, ( gnu local gp >> 16) 
addiu  $sp, -0x20 
la $gp, (__gnu_local_gp € OxFFFF) 
SW $ra, Ox20+saved RA($sp) 
SW $s0, Ox20+saved SO($sp) 
SW $gp, 0x204saved GP($sp) 


strlen() la prendra d'ici: 


lw $t9, (strlen € OxFFFF) ($gp) 
or $at, $zero ; slot de délai de chargement, NOP 
jalr $t9 


$s0: 
move $s0, $a0 ; slot de délai de branchement 


dans $v0 
; sauter à la sortie si $v0==0 (i.e., la longueur de la chaine est 0): 


beqz $v0, exit 
or $at, $zero ; slot de délai de branchement, NOP 
addiu $al, $v0, -1 
; $al = $v0-1 = str len-1 
addu $al, $s0, $al 
; $al = adresse de la chaíne en entrée + $al = s+strlen-1 
charger l'octet à l'adresse $al: 
lb $a0, 0($a1) 
or $at, $zero ; slot de délai de chargement, NOP 
; est-ce que l'octet est zéro? sauter à la sortie si oui: 
beqz $a0, exit 
or $at, $zero ; slot de délai de branchement, NOP 
addiu $v1, $v0O, -2 
; $v1 = str len-2 
addu $v1, $s0, $vl 
; $vl = $s0+$v1 = s+str_len-2 


li $a2, OxD 
; sauter le corps de boucle: 

b loc 6C 

li $a3, OxA ; slot de délai de branchement 
loc 5C: 
; charger l'octet suivant de la mémoire dans $a0: 

lb $a0, 0($v1) 

move $al, $v1 


; $al=ststr_len-2 
; sauter à la sortie si l'octet chargé est zéro: 
beqz $a0, exit 


l'adresse de la chaine en entrée est toujours dans $a0, mettons la dans 


le résultat de strlen() (i.e., la longueur de la chaine) est maintenant 


appeler strlen(). l'adresse de la chaine en entrée est toujours dans $a0, 
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; décrémenter str len: 

addiu $v1, -1 ; slot de délai de branchement 
loc 6C: 
; à ce moment, $a0-octet chargé, $a2=0xD (symbole CR) et $a3=0xA (symbole LF) 
; l'octet chargé est CR? sauter alors en loc 7C: 


beq $a0, $a2, loc 7C 
addiu $v0, -1 ; slot de délai de branchement 
; l'octet chargé est LF? sauter à la sortie si ce n'est pas LF: 
bne $a0, $a3, exit 
or $at, $zero ; slot de délai de branchement, NOP 


loc 7C: 
; l'octet chargé est CR à ce moment 
; sauter en loc 5c (début du corps de la boucle) si str len (dans $v0) n'est 
pas zéro: 
bnez $vO, loc 5C 
; simultanément, stocker zéro à cet endroit en mémoire: 


sb $zero, O0($al) ; slot de délai de branchement 
; le label "exit" à été renseigné manuellemnt: 
exit: 

lw $ra, 0x20+saved_RA($sp) 

move $vO, $s0 

lw $s0, Ox20+saved SO($sp) 

jr $ra 

addiu $sp, 0x20 ; slot de délai de branchement 


Les registres préfixés avec S- sont aussi appelés «saved temporaries » (sauvé tem- 
porairement), donc la valeur de $50 est sauvée dans la pile locale et restaurée à la 
fin. 


3.19 Fonction toupper() 


Une autre fonction courante transforme un symbole de minuscule en majuscule, si 
besoin: 


char toupper (char c) 


1 
if(c>='a' && c<='z') 
return c-'a'+'A'; 
else 
return c; 
} 


L'expression 'a'+'A' est laissée dans le code source pour améliorer la lisibilité, elle 
sera optimisée par le compilateur, bien sûr. ?!. 


Le code ASCII de «a» est 97 (ou 0x61), et celui de «A», 65 (ou 0x41). 


La différence (ou distance) entre les deux dans la table ASCII est 32 (ou 0x20). 


21Toutefois, pour être méticuleux, il y a toujours des compilateurs qui ne peuvent pas optimiser de telles 
expressions et les laissent telles quelles dans le code. 


OOAONDADUBWNEH 
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Pour une meilleure compréhension, le lecteur peut regarder la table ASCII 7-bit stan- 
dard: 


Fig. 3.3: table ASCII 7-bit dans Emacs 


3.19.1 x64 
Deux opérations de comparaison 


MSVC sans optimisation est direct: le code vérifie si le symbole en entrée est dans 
l'intervalle [97..122] (ou dans l'intervalle [‘a’..‘z’]) et soustrait 32 si c'est le cas. 


Il y a quelques artefacts du compilateur: 
Listing 3.73 : MSVC 2013 (x64) sans optimisation 


c$ = 8 
toupper PROC 

mov BYTE PTR [rsp+8], cl 

movsx eax, BYTE PTR c$[rsp] 

cmp eax, 97 

jl SHORT $LN2@toupper 

movsx eax, BYTE PTR c$[rsp] 

cmp eax, 122 

jg SHORT $LN2@toupper 

movsx eax, BYTE PTR c$[rsp] 

sub eax, 32 

jmp SHORT $LN3@toupper 

jmp SHORT $LN1Gtoupper ; artefact du compilateur 
$LN2@toupper: 

movzx eax, BYTE PTR c$[rsp] ; casting inutile 
$LN1@toupper: 
$LN3@toupper: ; artefact du compilateur 

ret 0 


toupper ENDP 


Il est important de remarquer que l'octet en entrée est chargé dans un slot 64-bit 
de la pile locale a la ligne 3. 


Tous les bits restants ([8..e3]) ne sont pas touchés, i.e., contiennent du bruit indéter- 
miné (vous le verrez dans le débogueur). 


Toutes les instructions opérent seulement au niveau de l'octet, donc c'est bon. 
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La derniére instruction MOVZX à la ligne 15 prend un octet de la pile locale et l'étend 
avec des zéro à un type de donnée int 32-bit. 


GCC sans optimisation fait essentiellement la méme chose: 
Listing 3.74 : GCC 4.9 (x64) sans optimisation 


toupper: 
push rbp 
mov rbp, rsp 
mov eax, edi 
mov BYTE PTR [rbp-4], al 
cmp BYTE PTR [rbp-4], 96 
jte .L2 
cmp BYTE PTR [rbp-4], 122 
jg .L2 
movzx eax, BYTE PTR [rbp-4] 
sub eax, 32 
jmp .L3 
.L2: 
movzx eax, BYTE PTR [rbp-4] 
.L3: 
pop rbp 
ret 


Une opération de comparaison 


MSVC avec optimisation fait un meilleur travail, il ne génére qu'une seule opération 
de comparaison: 


Listing 3.75 : MSVC 2013 (x64) avec optimisation 


toupper PROC 


lea eax, DWORD PTR [rcx-97] 
cmp al, 25 
ja SHORT $LN2@toupper 
movsx eax, cl 
sub eax, 32 
ret 0 
$LN2@toupper: 
movzx eax, cl 
ret 0 


toupper ENDP 


Il a déjà été expliqué comment remplacer les deux opérations de comparaison par 
une seule: 3.13.2 on page 647. 


Nous allons maintenant récrire ceci en C/C++: 


int tmp=c-97; 


if (tmp>25) 

return C; 
else 

return c-32; 


OY UI! 3$ W NJ H 
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La variable tmp doit étre signée. 


Cela fait deux opérations de soustraction en cas de transformation plus une compa- 
raison. 


Par contraste, l'algorithme original utilise deux opérations de comparaison plus une 
soustraction. 


GCC avec optimisation est encore meilleur, il supprime le saut (ce qui est bien: 2.4.1 
on page 589) en utilisant l'instruction CMOVcc: 


Listing 3.76 : GCC 4.9 (x64) avec optimisation 


toupper: 
lea edx, [rdi-97] ; 0x61 
lea eax, [rdi-32] ; 0x20 
cmp dl, 25 
cmova eax, edi 
ret 


À la ligne 3 le code prépare la valeur soustraite en avance, comme si la conversion 
avait toujours lieu. 


À la ligne 5 la valeur soustraite dans EAX est remplacée par la valeur en entrée 
non modifiée si la conversion n'est pas nécessaire. Et ensuite cette valeur (bien sür 
incorrecte) est abandonnée. 


La soustraction en avance est le prix que le compilateur paye pour l'absence de saut 
conditionnel. 


3.19.2 ARM 
Keil avec optimisation pour le mode ARM génére aussi une seule comparaison: 


Listing 3.77 : avec optimisation Keil 6/2013 (Mode ARM) 


toupper PROC 
SUB r1,r0,#0x61 
CMP r1,#0x19 
SUBLS r0,r0,#0x20 
ANDLS r0, r0, #0xf f 
BX lr 


Les instructions SUBLS et ANDLS ne sont exécutées que si la valeur dans R1 est 
inférieure à 0x19 (ou égale). 


Keil avec optimisation pour le mode Thumb génère lui aussi une seule opération de 
comparaison: 


Listing 3.78 : avec optimisation Keil 6/2013 (Mode Thumb) 


toupper PROC 
MOVS r1,ro 
SUBS r1,r1,#0x61 
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CMP r1,#0x19 

BHI |LO.14| 

SUBS r0,r0,#0x20 

LSLS r0,r0,#24 

LSRS r0,r0,#24 
|LO.14| 

BX lr 

ENDP 


Les deux dernières instructions LSLS et LSRS fonctionnent comme AND reg, OxFF : 
elles sont équivalentes à l'expression C/C++ (i «« 24) >> 24. 


Il semble que Keil pour le mode Thumb déduit que ces deux instructions de 2-octets 
sont plus courtes que le code qui charge la constante OxFF dans un registre plus une 
instruction AND. 


GCC pour ARM64 


Listing 3.79 : GCC 4.9 (ARM64) sans optimisation 


toupper: 
sub sp, sp, £16 
strb w0, [sp,15] 
ldrb w0, [sp,15] 
cmp w0, 96 


bls .L2 
ldrb w0, [sp,15] 
cmp w0, 122 
bhi .L2 
ldrb w0, [sp,15] 
sub w0, w0, #32 
uxtb w0, wO 
b .L3 
.L2: 
ldrb w0, [sp,15] 
.L3: 
add sp, sp, 16 
ret 
Listing 3.80 : GCC 4.9 (ARM64) avec optimisation 
toupper: 
uxtb w0, wO 
sub wl, w0, #97 
uxtb wl, wl 
cmp wl, 25 
bhi .L2 
sub w0, w0, #32 
uxtb w0, wO 
.L2: 
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3.19.3 Utilisation d'opérations sur les bits 


Étant donné le fait que le bit d'indice 5 (en partant depuis 0) est toujours présent 
après le test, soustraire revient juste à effacer ce seul bit, mais la méme chose peut 
étre effectuée avec un AND. 


Encore plus simple, en XOR-ant: 


char toupper (char c) 
1 
if(c>='a' && c<='z') 
return c^0x20; 
else 
return c; 
} 


Le code est proche de ce GCC avec optimisation a produit pour l'exemple précédent 
(3.76 on page 689) : 


Listing 3.81 : GCC 5.4 (x86) avec optimisation 


toupper: 
mov edx, DWORD PTR [esp+4] 
lea ecx, [edx-97] 
mov eax, edx 
xor eax, 32 
cmp cl, 25 
cmova eax, edx 
ret 


...mais XOR est utilisé au lieu de SUB. 


Changer le bit d'indice 5 est juste déplacer un curseur dans la table ASCII en haut 
ou en bas de deux lignes. 


Certains disent que les lettres minuscules/majuscules ont été placées de cette facon 
dans la table ASCII intentionnellement, car: 


Very old keyboards used to do Shift just by toggling the 32 or 16 
bit, depending on the key; this is why the relationship between small 
and capital letters in ASCII is so regular, and the relationship between 
numbers and symbols, and some pairs of symbols, is sort of regular if 
you squint at it. 


( Eric S. Raymond, http: //www.catb.org/esr/fags/things-every-hacker-once- knew/ 


) 


Donc, nous pouvons écrire ce morceau de code, qui change juste la casse des lettres: 


#include <stdio.h> 


char flip (char c) 
{ 
if((c>='a' && c<='z') || (c>='A' 68 c<='Z')) 
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return c^0x20; 


else 
return c; 
} 
int main() 
{ 
// affichera "hELLO, WORLD!" 
for (char *s="Hello, world!"; *s; s++) 
printf ("%c", flip(*s)); 
}; 


3.19.4 Summary 


Toutes ces optimisations de compilateurs sont aujourd'hui courantes et un rétro- 
ingénieur pratiquant voit souvent ce genre de patterns de code. 


3.20 Obfuscation 


L'obfuscation est une tentative de cacher le code (ou sa signification) aux rétro- 
ingénieurs. 


3.20.1 Chaines de texte 


Comme nous l'avons vu dans (5.4 on page 914), les chaînes de texte peuvent être 
vraiment utiles. 


Les programmeurs qui sont conscients de ceci essayent de les cacher, rendant im- 
possible de trouver la chaine dans IDA ou tout autre éditeur hexadécimal. 


Voici la méthode la plus simple. 


La chaine peut étre construite comme ceci: 


mov byte ptr [ebx], 'h' 
mov byte ptr [ebx+1], 'e' 
mov byte ptr [ebx+2], 'l' 
mov byte ptr [ebx+3], 'l' 
mov byte ptr [ebx+4], 'o' 
mov byte ptr [ebx+5], ' ' 
mov byte ptr [ebx+6], 'w' 
mov byte ptr [ebx+7], 'o' 
mov byte ptr [ebx+8], 'r' 
mov byte ptr [ebx+9], 'l' 
mov byte ptr [ebx+10], 'd' 


La chaine peut aussi étre comparée avec une autre comme ceci: 


mov ebx, offset username 
cmp byte ptr [ebx], 'j' 
jnz fail 
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cmp byte ptr [ebx+1], 'o' 
jnz fail 

cmp byte ptr [ebx+2], 'h' 
jnz fail 

cmp byte ptr [ebx+3], 'n' 
jnz fail 

jz it is john 


Dans les deux cas, il est impossible de trouver ces chaínes directement dans un 
éditeur hexadécimal. 


À propos, ceci est un moyen de travailler avec des chaínes lorsqu'il est impossible 
d'allouer de l'espace pour elles dans le segment de données, par exemple dans un 
PIC22 ou un shellcode. 


Une autre méthode est d'utiliser sprintf() pour la construction: 


sprintf(buf, "%s%c%s%c%s", "hel",'l',"o w",'o',"rld"); 


Le code semble bizarre, mais peut étre utile comme simple mesure anti-reversing. 


Les chaínes de texte peuvent aussi étre présentes dans une forme chiffrée, donc 
chaque utilisation d'une chaîne est précédée par une routine de déchiffrement. Par 
exemple: 8.8.2 on page 1091. 


3.20.2 Code exécutable 
Insertion de code inutile 


L'obfuscation de code exécutable implique l'insertion aléatoire de code inutile dans 
le code réel, qui s'exécute mais ne fait rien d'utile. 


Un simple exemple: 


Listing 3.82 : code original 


add eax, ebx 
mul ecx 
Listing 3.83 : code obfusqué 

xor esi, 011223344h ; inutile 

add esi, eax ; inutile 

add eax, ebx 

mov edx, eax ; inutile 

shl edx, 4 ; inutile 

mul ecx 

xor esi, ecx ; inutile 


Ici, le code inutile utilise des registres qui ne sont pas utilisés dans le code réel (ESI 
et EDX). Toutefois, les résultats intermédiaires produit par le code réel peuvent être 
utilisés par les instructions inutiles pour brouiller les pistes—pourquoi pas? 


22 Position Independent Code 
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Remplacer des instructions avec des équivalents plus gros 


* MOV op1, op2 peut être remplacé par la paire PUSH op2 / POP opl. 


* JMP label peut étre remplacé par la paire PUSH label / RET.IDA ne montrera 
pas la référence au label. 


* CALL label peut étre remplacé par le triplet d'instructions suivant: 
PUSH label after CALL instruction / PUSH label / RET. 


* PUSH op peut aussi étre remplacé par la paire d'instructions suivante: 
SUB ESP, 4 (or 8) / MOV [ESP], op. 


Code toujours exécuté/jamais exécuté 


Si le développeur est certain que ESI contient toujours 0 à ce point: 


mov esi, 1 

M ; du code qui ne change pas ESI 
dec esi 

T ; du code qui ne change pas ESI 
cmp esi, 0 

jz real code 

; fake code 

real code: 


Le rétro-ingénieur a parfois besoin de temps pour le comprendre. 
Ceci est aussi appelé un prédicat opaque. 


Un autre exemple (et de nouveau, le développeur est certain que ESI vaut toujours 
zéro) : 


; ESI=0 

add eax, ebx ; code réel 

mul ecx ; code réel 

add eax, esi ; prédicat opaque. 


; XOR, AND ou SHL, etc, peuvent étre ici au lieu de ADD. 


Mettre beaucoup de bazar 


instruction 1 
instruction 2 
instruction 3 


Peut étre remplacé par: 


begin: jmp insl label 
ins2 label: instruction 2 

jmp ins3 label 
ins3 label: instruction 3 


jmp exit: 
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insl label: instruction 1 


jmp 
exit: 


ins2 label 


Utilisation de pointeurs indirects 


dummy datal db 
messagel db 


dummy data2 db 
message2 db 


func proc 
mov 
add 
push 
call 
mov 
add 


push 
call 


func endp 


100h dup (0) 
‘hello world',0 


200h dup (0) 
'another message',0 


eax, offset dummy datal ; PE or ELF reloc here 
eax, 100h 

eax 

dump string 


eax, offset dummy data2 ; PE or ELF reloc here 
eax, 200h 

eax 

dump string 


IDA montrera seulement les références à dummy datal et dummy data2, mais pas 


aux chaines de textes. 


Les variables globales et méme les fonctions peuvent étre accédées comme ca. 


Maintenant, quelque chose de légérement plus avancé. 


Franchement, je ne connais pas con nom exact, mais je vais l'appeler pointeur déca- 
lés. Cette technique est assez commune, au moins dans les systémes de protection 


contre la copie. 


En bref: lorsque vous écrivez une valeur dans la mémoire globale, vous utilisez une 
adresse, mais lorsque vous lisez, vous utilisez la somme d'une (autre) adresse, ou 
peut-étre une différence. Le but est de cacher l'adresse réelle au rétro-ingénieur qui 
débogue le code ou l'explore dans IDA (ou un autre désassembleur). 


Ceci peut étre pénible. 


#include <stdio.h> 


// 64KiB, but it's OK 


unsigned char secret array[0x10000]; 


void check lic key() 
1 


// pretend licence check has been failed 
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secret array[0x6123]-1; // 1 mean failed 
printf ("check failed\n"); // exit(0); // / a cracker may patch here 


// or put there another value if check is succeeded 
secret array[0x6123]-0; 


}; 
unsigned char get byte at _Ox6000 (unsigned char *a) 
1 
return *(a+0x6000) ; 
}; 
void check again() 
1 
if (get byte at _0x6000(secret_array+0x123)==1) 
1 
// do something mean (add watermark maybe) or report error: 
printf ("check failedin"); 
} 
else 
{ 
// proceed further 
}; 
}; 
int main() 
{ 
// at start: 
check lic key(); 
// do something 
// ... and while in some very critical part: 
check again(); 
}; 


Compiler avec MSVC 2015 sans optimisation: 


_check lic key proc near 


push ebp 

mov ebp, esp 

mov eax, 1 

imul ecx, eax, 6123h 

mov secret array[ecx], 1 
pop ebp 

retn 


check lic key endp 


get byte at 0x6000 proc near 


a - dword ptr 8 
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push ebp 

mov ebp, esp 

mov eax, [ebp+a] 
mov al, [eax+6000h] 
pop ebp 

retn 


_get_byte at_0x6000 endp 


check again proc near 
push ebp 
mov ebp, esp 


push offset point passed to get byte at 0x6000 
call j get byte at 0x6000 


add esp, 4 
movzx  eax, al 
cmp eax, 1 
jnz short loc 406735 
push offset Format ; "check failed\n" 
call j printf 
add esp, 4 
loc 406735: 
pop ebp 
retn 
check again endp 


.data:0045F5C0 ; char secret array[65536] 

.data:0045F5C0 secret array db 123h dup(?) 

.data:0045F6E3 ; char point passed to get byte at 0x6000[65245] 
.data:0045F6E3 point passed to get byte at 0x6000 db OFEDDh dup(?) 


Vous voyez, IDA obtient seulement deux adresses: secret array[] (début du ta- 
bleau) et point passed to get byte at 0x6000. 


Comment s'y prendre: vous pouvez utiliser les point d'arrét matériel sur les opéra- 
tions d'accés en mémoire, tracer posséde l'option BPMx) ou des moteurs d'exécution 
symbolique ou peut-étre écrire un module pour IDA ... 


C'est sür, un tableau peut étre utiliser pour des nombreuses valeurs, non limité aux 
booléennes... 


N.B.: MSVC 2015 avec optimisation est assez malin pour optimiser la fonction 
get byte at 0x6000(). 


3.20.3 Machine virtuelle / pseudo-code 


Un programmeur peut construire son propre LP ou ISA et son interpréteur. 


(Comme le Visual Basic pre-5.0, .NET ou les machines Java). Le rétro-ingénieur aura 
besoin de passer du temps pour comprendre la signification et les détails de toutes 
les instructions de l'ISA. 


Il/elle devra aussi une sorte de désassembleur/décompilateur. 
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3.20.4 Autres choses à mentionner 


Ma propre (faible pour le moment) tentative de patch du compilateur Tiny C pour 
produire du code obfusqué: http://blog.yurichev.com/node/58. 


Utiliser l'instruction MOV pour des choses vraiment compliquées: [Stephen Dolan, 
mov is Turing-complete, (2013)] 2. 


3.20.5 Exercice 
* http://challenges.re/29 


3.21 C++ 


3.21.1 Classes 
Un exemple simple 


En interne, la représentation des classes C++ est presque la méme que les struc- 
tures. 


Essayons un exemple avec deux variables, deux constructeurs et une méthode: 


#include <stdio.h> 


class c 
{ 
private: 
int vl; 
int v2; 
public: 
c() // ctor par défaut 
{ 
v1=667; 
v2=999; 
i 
c(int a, int b) // ctor 
1 
vl=a; 
v2=b; 
}; 
void dump() 
1 
printf ("%d; %d\n", v1, v2); 
}; 
}; 
int main() 
{ 


23Aussi disponible en http://www.cl.cam.ac.uk/-sd601/papers/mov.pdf 
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class c cl; 
class c c2(5,6); 


cl.dump(); 
c2.dump() ; 
return 0; 
}; 
MSVC: x86 


Voici à quoi ressemble la fonction main(), traduite en langage d'assemblage: 


Listing 3.84 : MSVC 


_c2$ = -16 ; size = 8 
_cl$ 2-8 ; size = 8 
_main PROC 

push ebp 

mov ebp, esp 

sub esp, 16 


lea ecx, DWORD PTR c1$[ebp] 
call ??0cQGGQAEQXZ ; c::c 
push 6 
push 5 
lea ecx, DWORD PTR c2$[ebp] 
call ??@c@@QAE@HH@Z ; c::c 
lea ecx, DWORD PTR c1$[ebp] 
call ?dump@c@@QAEXXZ ; c::dump 
lea ecx, DWORD PTR c2$[ebp] 
call ?dump@c@@QAEXXZ ; c::dump 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

_main ENDP 


Voici ce qui se passe. Pour chaque objet (instance de la classe c) 8 octets sont alloués, 
exactement la taille requise pour stocker les deux variables. 


Pour c1 un constructeur par défaut sans argument ??0c@@QAE@XZ est appelé. Pour 
C2 un autre constructeur ??0c@@QAE@HH@Z est appelé et deux nombres sont passés 
comme arguments. 


Un pointeur sur l'objet (this en terminologie C++) est passé dans le registre ECX. 
Ceci est appelé thiscall (3.21.1)—la méthode pour passer un pointeur à l'objet. 


MSVC le fait en utilisant le regsitre ECX. Inutile de le dire, ce n'est pas une méthode 
standardisée, d'autres compilateurs peuvent le faire différemment, e.g., par le pre- 
mier argument de la fonction (comme GCC). 


Pourquoi est-ce que ces fonctions ont un nom aussi étrange? C'est le name mangling. 
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Une classe C++ peut contenir plusieurs méthodes partageant le méme nom mais 
ayant des arguments différents—c'est le polymorphisme. Et bien súr, différentes 
classes peuvent avoir leurs propres méthodes avec le méme nom. 


Le Name mangling nous permet d'encoder le nom de la classe + le nom de la mé- 
thode + tous les types des arguments de la méthode dans une chaíne ASCII, qui est 
ensuite utilisée comme le nom interne de la fonction. C'est ainsi car ni le linker, ni 
le chargeur de DLL de l'OS (les mangled names peuvent aussi se trouver parmi les 
exports de DLL) n'ont conscience de C++ ou de |’POO?4. 


La fonction dump() est appelée deux fois. 


Maintenant, regardons le code du constructeur: 


Listing 3.85 : MSVC 


_this$ = -4 ; size = 4 
??Q0c@@QAE@XZ PROC ; c::c, COMDAT 
; this$ = ecx 
push ebp 
mov ebp, esp 
push ecx 
mov DWORD PTR this$[ebp], ecx 
mov eax, DWORD PTR _this$[ebp] 
mov DWORD PTR [eax], 667 
mov ecx, DWORD PTR _this$[ebp] 
mov DWORD PTR [ecx+4], 999 
mov eax, DWORD PTR _this$[ebp] 
mov esp, ebp 
pop ebp 
ret 0 
??Qc@@QAE@XZ ENDP ; c::c 


_this$ = -4 ; size = 4 
_a$ = 8 ; size = 4 
_b$ = 12 ; size = 4 


??0c@@QAE@HH@Z PROC ; c::c, COMDAT 
; this$ = ecx 
push ebp 
mov ebp, esp 
push ecx 
mov DWORD PTR this$[ebp], ecx 
mov eax, DWORD PTR _this$[ebp] 
mov ecx, DWORD PTR _a$[ebp] 
mov DWORD PTR [eax], ecx 
mov edx, DWORD PTR _this$[ebp] 
mov eax, DWORD PTR _b$[ebp] 
mov DWORD PTR [edx+4], eax 
mov eax, DWORD PTR _this$[ebp] 
mov esp, ebp 
pop ebp 
ret 8 
??Qc@@QAE@HH@Z ENDP ; c::c 


2 Programmation orientée objet 
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Les constructeurs sont juste des fonctions, ils utilisent un pointeur sur la structure 
dans ECX, en copiant le pointeur dans leur propre variable locale, toutefois, ce n'est 
pas nécessaire. 


D'aprés le standard (C++11 12.1) nous savons que les constructeurs n'ont pas l'obli- 
gation de renvoyer une valeur. 


En fait, en interne, les constructeurs renvoient un pointeur sur l'objet nouvellement 
créé, i.e., this. 


Maintenant, la méthode dump) : 


Listing 3.86 : MSVC 


_this$ = -4 ; size = 4 
?dump@c@@QAEXXZ PROC ; c::dump, COMDAT 
; this$ = ecx 

push ebp 

mov ebp, esp 

push ecx 

mov DWORD PTR this$[ebp], ecx 

mov eax, DWORD PTR this$[ebp] 

mov ecx, DWORD PTR [eax+4] 

push ecx 

mov edx, DWORD PTR _this$[ebp] 

mov eax, DWORD PTR [edx] 

push eax 

push OFFSET ?? C@ 07NJBDCIECQ?$CFd?$DL?5?$CFd?6?$AAQ 

call printf 


add esp, 12 
mov esp, ebp 
pop ebp 

ret 0 


?dump@c@@QAEXXZ ENDP ; c::dump 


Assez simple: dump() prend un pointeur sur la structure qui contient les deux int 
dans ECX, prend les deux valeurs et les passe à printf(). 


Le code est bien plus court s'il est compilé avec les optimisations (/0x) : 


Listing 3.87 : MSVC 


??20cQQQAEQXZ PROC ; c::c, COMDAT 
; this$ = ecx 
mov eax, ecx 
mov DWORD PTR [eax], 667 
mov DWORD PTR [eax+4], 999 
ret 0 
??Q0c@@QAE@XZ ENDP ; c::c 


_a$ 8 ; size 4 
_b$ 12 ; size 4 
??Q0c@@QAE@HH@Z PROC ; c::c, COMDAT 
; this$ = ecx 
mov edx, DWORD PTR _b$[esp-4] 
mov eax, ecx 
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mov ecx, DWORD PTR _a$[esp-4] 
mov DWORD PTR [eax], ecx 
mov DWORD PTR [eax+4], edx 
ret 8 

??Qc@@QAE@HH@Z ENDP ; c::c 


?dump@c@@QAEXXZ PROC ; c::dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+4] 
mov ecx, DWORD PTR [ecx] 
push eax 
push ecx 
push OFFSET ?? C@ 07NJBDCIECQ?$CFd?$DL?5?$CFd?6?$AAQ 
call printf 
add esp, 12 
ret 0 
?dump@c@@QAEXXZ ENDP ; c::dump 


C'esttout. L'autre chose que nous devons noter est que le pointeur de pile n'a pas été 
corrigé avec add esp, X après l'appel du constructeur. En méme temps, le construc- 
teur a ret 8 au lieu de RET à la fin. 


C'est parce que la convention d'appel thiscall (3.21.1 on page 699) est utilisée ici, qui, 
comme avec la méthode stdcall (6.1.2 on page 953), offre à l'appelée la possibilité 
de corriger la pile au lieu de l'appelante. L'instruction ret x ajoute X à la valeur de 
ESP, puis passe le contróle à la fonction appelante. 


Regardez la section parlant des conventions d'appel (6.1 on page 953). 


Il faut également noter que le compilateur décide quand appeler le constructeur et 
le destructeur—mais nous le savons déjà des bases du langage C++. 


MSVC: x86-64 


Comme nous le savons déjà, les 4 premiers arguments de fonction en x86-64 sont 
passés dans les registres RCX, RDX, R8 et R9, tous les autres— par la pile. 


Néanmoins, le pointeur this sur l'objet est passé dans RCX, le premier argument de 
la méthode dans RDX, etc. Nous pouvons le voir dans les entrailles de la méthode 
c(int a, int b): 


Listing 3.88 : MSVC 2012 x64 avec optimisation 


; void dump() 


?dump@c@@QEAAXXZ PROC ; c::dump 
mov r8d, DWORD PTR [rcx+4] 
mov edx, DWORD PTR [rcx] 
lea rcx, OFFSET FLAT:?? C@ 07NJBDCIECQG?$CFd?$DL?5?$CFd?6?$AAQ ; 


jmp printf 
?dump@c@@QEAAXXZ ENDP ; c::dump 
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; c(int a, int b) 


??Q@c@@QEAAGHH@Z PROC ; c::c 


mov 
mov 
mov 
ret 


DWORD PTR [rcx], edx 


rax, rcx 
0 


??Qc@@QEAA@HH@Z ENDP ; c::c 


; default ctor 


??0c@@QEAA@XZ PROC ; c::c 


mov 
mov 
mov 
ret 


DWORD PTR [rcx], 667 


DWORD PTR [rcx+4], 999 


rax, rcx 
0 


??0c@@QEAA@XZ ENDP ; c::c 


ler argument: 
DWORD PTR [rcx+4], r8d ; 2nd argument: 


a 
b 


Le type de donnée int est toujours 32-bit en x64 2°, c'est donc pourquoi les parties 


32-bit des registres sont utilisées ici. 


Nous voyons également JMP printf au lieu de RET dans la méthode dump(), astuce 


que nous avons déjà vu plus tót: 1.21.1 on page 205. 


GCC: x86 


C'est presque la méme chose avec GCC 4.4.1, avec quelques exceptions. 


Listing 3.89 : GCC 4.4.1 


public main 
main proc near 


var 20 
var 1C 
var 18 
var 10 
var 8 


push 
mov 
and 
sub 
lea 
mov 
call 
mov 
mov 
lea 
mov 
call 


dword ptr -20h 
dword ptr -1Ch 
dword ptr -18h 
dword ptr -10h 


dword ptr -8 
ebp 

ebp, esp 

esp, OFFFFFFFOh 
esp, 20h 


eax, [esp+20h+var 8] 
[esp+20h+var_20], eax 


_ZNIcCIEv 


[esp+20h+var_ 18], 6 
[esp*20h-var 1C], 5 
eax, [esp+20h+var_10] 
[esp+20h+var_20], eax 


_ZNIcCIEii 


25 Apparemment, pour faciliter le portage de code 32-bit C/C++ en x64 
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lea eax, [esp+20h+var_8] 
mov [esp+20h+var_ 20], eax 
call ZN1c4dumpEv 
lea eax, [esp+20h+var_10] 
mov [esp+20h+var_ 20], eax 
call _ZN1c4dumpEv 
mov eax, 0 
leave 
retn 

main endp 


Ici, nous voyons un autre style de name mangling, spécifique à GNU 2°. I| peut aus- 
si étre noté que le pointeur sur l'objet est passé comme premier argument de la 


fonction—invisible au programmeur, bien sûr. 


Premier constructeur: 


public  ZNICCIEv ; weak 


_ZN1cCIEv proc near ; CODE XREF: 
arg_0 = dword ptr 8 
push ebp 
mov ebp, esp 
mov eax, [ebp+arg 0] 
mov dword ptr [eax], 667 
mov eax, [ebp+arg 0] 
mov dword ptr [eax+4], 999 
pop ebp 
retn 
_ZNIcCIEv endp 


Il écrit juste les deux nombres en utilisant le pointeur passé comme premier (et seul) 


argument. 


Second constructeur: 


public ZNicCIEii 


_ZNIcCIEii proc near 

arg_0 = dword ptr 8 

arg_4 = dword ptr OCh 

arg_8 = dword ptr 10h 
push ebp 
mov ebp, esp 
mov eax, [ebp+arg_0] 
mov edx, [ebp+arg_4] 
mov [eax], edx 
mov eax, [ebp+arg 0] 


261| y a un bon document à propos des différentes conventions de name mangling dans différent com- 


pilateurs: 
[Agner Fog, Calling conventions (2015)]. 
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mov edx, [ebp+arg_8] 
mov [eax+4], edx 
pop ebp 
retn 

_ZN1cC1Eii endp 


Ceci est une fonction, l'analogue d'une qui pourrait ressembler à ceci: 


void ZN1cC1Eii (int *obj, int a, int b) 
1 
*obj-a; 
*(obj+1)=b; 
$; 


...et cela est entièrement prévisible. 


Maintenant, la fonction dump() : 


public ZNic4dumpEv 


_ZN1c4dumpEv proc near 
var_18 = dword ptr -18h 
var_14 = dword ptr -14h 
var_10 = dword ptr -10h 
arg_0 = dword ptr 8 
push ebp 
mov ebp, esp 
sub esp, 18h 
mov eax, [ebp+arg 0] 
mov edx, [eax+4] 
mov eax, [ebp+arg 0] 
mov eax, [eax] 
mov [esp+18h+var_10], edx 
mov [esp+18h+var_14], eax 
mov [esp+18h+var 18], offset aDD ; "%d; %d\n" 
call _printf 
leave 
retn 


_ZN1c4dumpEv endp 


La représentation interne de cette fonction a un seul argument, utilisé comme poin- 
teur sur l'objet (this). 


Cette fonction pourrait étre récrite en C comme ceci: 


void ZN1c4dumpEv (int *obj) 


1 
printf ("%d; %d\n", *obj, *(obj+1)); 
}; 


Ainsi, si nous basons notre jugement sur ces simples exemples, la différence entre 
MSVC et GCC est le style d'encodage des noms de fonctions (name mangling) et la 
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méthode pour passer un pointeur sur l'objet (via le registre ECX ou via le premier 
argument). 


GCC: x86-64 


Les 6 premiers arguments, comme nous le savons déja, sont passés par les registres 
RDI, RSI, RDX, RCX, R8 et R9 ([Michael Matz, Jan Hubicka, Andreas Jaeger, Mark Mit- 
chell, System V Application Binary Interface. AMD64 Architecture Processor Supple- 
ment, (2013)] ?”), et le pointeur sur this via le premier (RDI) et c'est ce que l'on voit 
ici. Le type de donnée int est aussi 32-bit ici. 


L'astuce du JMP au lieu de RET est aussi utilisée ici. 


Listing 3.90 : GCC 4.4.6 x64 


; ctor par défault 


_ZN1cC2Ev: 
mov DWORD PTR [rdi], 667 
mov DWORD PTR [rdi+4], 999 
ret 


; c(int a, int b) 


_ZN1cC2Eii: 
mov DWORD PTR [rdi], esi 
mov DWORD PTR [rdi+4], edx 
ret 


; dump () 


_ZN1c4dumpEv: 
mov edx, DWORD PTR [rdi+4] 
mov esi, DWORD PTR [rdi] 
xor eax, eax 
mov edi, OFFSET FLAT:.LCO ; "%d; %d\n" 
jmp printf 


Héritage de classe 


Les classes héritées sont similaires aux simples structures dont nous avons déja 
discuté, mais étendues aux classes héritables. 


Prenons ce simple exemple: 


#include <stdio.h> 
class object 


public: 


27Aussi disponible en  https://software.intel.com/sites/default/files/article/402129/ 
mpx- Linux64- abi. pdf 
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int color; 

object() { y; 

object (int color) 4 this->color=color; }; 

void print color() 4 printf ("color=%d\n", color); }; 


}; 
class box : public object 
1 
private: 
int width, height, depth; 
public: 
box(int color, int width, int height, int depth) 
1 
this->color=color; 
this->width=width; 
this->height=height; 
this->depth=depth; 
h 
void dump() 
{ 
printf ("this is a box. color=%d, width=%d, height=%d, depth=%d 
y Mn", color, width, height, depth); 
h 
}; 
class sphere : public object 
1 
private: 
int radius; 
public: 
sphere(int color, int radius) 
1 
this->color=color; 
this->radius=radius; 
}; 
void dump() 
{ 
printf ("this is sphere. color=%d, radius=%d\n", color, radius); 
}; 
}; 
int main() 
i 


box b(1, 10, 20, 30); 
sphere s(2, 40); 


b.print color(); 
s.print color(); 


b.dump() ; 
s.dump(); 


return 0; 
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PE 


Investiguons le code généré de la fonction/méthode dump () et aussi 
object::print color(),etregardons la disposition de la mémoire pour les structures- 
objets (pour du code 32-bit). 


Donc, voici les méthodes dump() pour quelques classes, générées par MSVC 2008 
avec les options /0x et /0b07°. 


Listing 3.91 : MSVC 2008 avec optimisation /ObO 
?? C@ O9GCEDOLPA@color?$DN?$CFd?6?$AA@ DB 'color=%d', O0aH, OOH ; string' 
?print_color@object@@QAEXXZ PROC ; object::print color, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx] 
push eax 


; 'color=%d', OaH, OOH 
push OFFSET ?? C@ O9GCEDOLPA@color?$DN?$CFd?6?$AA@ 
call printf 
add esp, 8 
ret 0 
?print_color@object@@QAEXXZ ENDP ; object::print color 


Listing 3.92 : MSVC 2008 avec optimisation /ObO 


?dump@box@@QAEXXZ PROC ; box::dump, COMDAT 
; this$ = ecx 

mov eax, DWORD PTR [ecx+12] 

mov edx, DWORD PTR [ecx+8] 

push eax 

mov eax, DWORD PTR [ecx+4] 

mov ecx, DWORD PTR [ecx] 

push edx 

push eax 

push ecx 


‘this is a box. color=%d, width=%d, height=%d, depth=%d', 0aH, 00H ; ‘string 
push OFFSET ?? Cf ODG@NCNGAADL@this?5is?5box?4?5color?$DN?$CFd?0?5widthy 
y ?$DN?$CFd?0@ 
call printf 
add esp, 20 
ret 0 

?dump@box@@QAEXXZ ENDP ; box::dump 


Listing 3.93 : MSVC 2008 avec optimisation /ObO 
?dump@sphere@@QAEXXZ PROC ; sphere::dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+4] 


281 ‘option /0b0 signifie la désactivation de l'expension inline, puisque la mise en ligne de fonctions peut 
rendre notre expérience plus difficile. 
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mov 
push 
push 


, 


ecx, DWORD PTR [ecx] 
eax 
ecx 


‘this is sphere. color=%d, radius=%d', OaH, 00H 


push OFFSET ?? C@ OCF@EFEDJLDC@this?5is?5sphere?4?5color?$DN?$CFd?0?5 7 
V radius 


call 
add 
ret 


| printf 
esp, 12 
0 


?dump@sphere@@QAEXXZ ENDP ; sphere::dump 


Donc, voici la disposition de la mémoire: 


(classe de base object) 


offset | description 


+0x0 int color 


(classes héritées) 


box : 


sphere : 


offset | description 


+0x0 int color 


+0x4 int width 


+0x8 | int height 


+0xC | int depth 


offset | description 


+0x0 int color 


+0x4 | int radius 


Regardons le corps de la fonction main() : 


Listing 3.94 : MSVC 2008avec optimisation /ObO 


PUBLIC main 
. TEXT SEGMENT 


_s$ = -24 ; size = 8 

_b$ = -16 ; size = 16 

_main PROC 
sub esp, 24 
push 30 
push 20 
push 10 
push 1 
lea ecx, DWORD PTR _b$[esp+40] 
call ??@box@@QAE@HHHH@Z ; box: :box 
push 40 
push 2 
lea ecx, DWORD PTR _s$[esp+32] 
call ??@sphere@@QAE@HH@Z ; sphere::sphere 
lea ecx, DWORD PTR _b$[esp+24] 
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call ?print_color@object@@QAEXXZ ; object: :print color 
lea ecx, DWORD PTR _s$[esp+24] 
call ?print_color@object@@QAEXXZ ; object::print color 
lea ecx, DWORD PTR _b$[esp+24] 
call ?dump@box@@QAEXXZ ; box: :dump 
lea ecx, DWORD PTR _s$[esp+24] 
call ?dump@sphere@@QAEXXZ ; sphere: :dump 
xor eax, eax 
add esp, 24 
ret 0 
main ENDP 


Les classes héritées doivent toujours ajouter leurs champs aprés les champs de la 
classe de base, afin que les méthodes de la classe de base puissent travailler avec 
ses propres champs. 


Lorsque la méthode object::print color() est appelée, un pointeur sur les deux 
objets box et sphere est passé en this, et il peut travailler facilement avec ces 
objets puisque le champ color dans ces objets est toujours à l'adresse épinglée (à 
l'offset +0x0). 


On peut dire que la méthode object::print color() est agnostique en relation 
avec le type d'objet en entrée tant que les champs sont épinglés à la méme adresse 
et cette condition est toujours vraie. 


Et si vous créez une classe héritée de la classe box, le compilateur ajoutera les 
nouveaux champs aprés le champ depth, laissant les champs de la classe box à 
l'adresse épinglée. 


Ainsi, la méthode box: : dump ( ) fonctionnera correctement pour accéder aux champs 
color, width, height et depth, qui sont toujours positionnés à l'adresse connue. 


Le code généré par GCC est presque le méme, avec la seule exception du passage 
du pointeur this (comme il a déjà été expliqué plus haut, il est passé en premier 
argument au lieu d'utiliser le registre ECX). 


Encapsulation 


L'encapsulation consiste à cacher les données dans des sections private de la classe, 
e.g. de n'autoriser leurs accés que depuis les méthodes de la classe. 


Toutefois, y a-t-il des repéres dans le code à propos du fait que certains champs sont 
privé et d'autres—non? 


Non, il n'y a pas de tels repéres. 


Essayons avec ce simple exemple: 


#include <stdio.h> 


class box 


{ 
private: 
int color, width, height, depth; 
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public: 
box(int color, int width, int height, int depth) 
1 
this->color=color; 
this->width=width; 
this->height=height ; 
this->depth=depth; 
h 
void dump() 
1 


printf ("this is a box. color=%d, width=%d, height=%d, depth=%d” 
y Mn", color, width, height, depth); 
}; 
}; 


Compilons-le à nouveau dans MSVC 2008 avec les options /0x et /0b0 puis regar- 
dons le code de la méthode box: :dump() : 


?dump@box@@QAEXXZ PROC ; box::dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+12] 
mov edx, DWORD PTR [ecx+8] 
push eax 
mov eax, DWORD PTR [ecx+4] 
mov ecx, DWORD PTR [ecx] 
push edx 
push eax 
push ecx 
'this is a box. color=%d, width=%d, height=%d, depth=%d', 0aH, 00H 
push OFFSET ?? C@ ODGENCNGAADLEthis?5is?5box?4?5color?$DN?$CFd?0?5width 
S ?$DN?$CFd?0@ 
call printf 
add esp, 20 
ret 0 
?dump@box@@QAEXXZ ENDP ; box: :dump 


Voici l'agencement mémoire de la classe: 


offset | description 
+0x0 | int color 
+0x4 | int width 
+0x8 | int height 
+0xC | int depth 


Tous les champs sont privés et ne peuvent étre accédés depuis une autre fonc- 
tion, mais connaissant cette disposition, pouvons-nous créer le code qui modifie ces 
champs? 


Pour faire ceci, nous ajoutons la fonction hack oop encapsulation(), qui ne com- 
pilerait pas si elle ressemblait à ceci: 


void hack oop encapsulation(class box * o) 


{ 


o->width=1; // ce code ne paut pas étre compilé: 
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// "error C2248: 'box::width' : cannot access private member | 
declared in class 'box'" 


D: | 


Néanmoins, si nous castons le type box sur un pointeur sur un tableau de int, que 
nous modifions le tableau de int-s que nous avons, nous pourrions réussir. 


void hack oop encapsulation(class box * o) 

1 
unsigned int *ptr to object-reinterpret cast«unsigned int*>(0); 
ptr to object[1]=123; 

}; 


Le code de cette fonction est très simple—on peut dire que la fonction prend un 
pointeur sur un tableau de int-s en entrée et écrit 123 dans le second int : 


?hack_oop_encapsulation@@YAXPAVbox@@@Z PROC ; hack oop encapsulation 
mov eax, DWORD PTR _o$[esp-4] 
mov DWORD PTR [eax+4], 123 
ret 0 

?hack_oop_encapsulation@@YAXPAVbox@@@Z ENDP ; hack oop encapsulation 


Regardons comment ça fonctionne: 


int main() 

{ 
box b(1, 10, 20, 30); 
b.dump(); 


hack_oop_encapsulation(&b) ; 


b.dump(); 
return 0; 
}; 
Lançons-le: 


this is a box. color=1, width=10, height=20, depth=30 
this is a box. color=1, width=123, height=20, depth=30 


Nous voyons que l'encapsulation est juste une protection des champs de la classe 
lors de l'étape de compilation. 


Le compilateur C++ n'autorise pas la génération de code qui modifie directement 
les champs protégés, néanmoins, il est possible de le faire avec l'aide de dirty hacks. 


Héritage multiple 


L'héritage multiple est la création d'une classe qui hérite des champs et méthodes 
de deux classes ou plus. 


Écrivons à nouveau un exemple simple: 
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#include <stdio.h> 


class box 
{ 
public: 
int width, height, depth; 
box() { }; 
box(int width, int height, int depth) 
{ 
this->width=width; 
this->height=height ; 
this->depth=depth; 
}; 
void dump() 
1 


printf ("this is a box. width=%d, height=%d, 
S , height, depth); 
h 
int get volume() 


1 
}; 


return width * height * depth; 
}; 


class solid object 
{ 
public: 
int density; 
solid object() { }; 
solid object(int density) 


this->density=density; 
F 
int get_density() 
{ 


}; 
void dump() 
{ 


return density; 


depth=%d\n", width 


printf ("this is a solid_object. density=%d\n", density); 


}; 
}; 


class solid box: box, solid object 


{ 
public: 


solid box (int width, int height, int depth, int density) 


1 
this->width=width; 
this->height=height; 
this->depth=depth; 
this->density=density; 
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void dump() 


printf ("this is a solid box. width=%d, height=%d, depth=%d, 7 
& density=%d\n", width, height, depth, density); 


int get weight() { return get volume() * get density(); }; 


int main() 


box b(10, 20, 30); 
solid object so(100); 
solid box sb(10, 20, 30, 3); 


b.dump( 
so.dump 
sb.dump 
printf 


T 
) 


) 
( 
( 
( 


ge -- - 


din", sb.get weight()); 


return 0; 


}; 


Compilons-le avec MSVC 2008 avec les options /0x et /0b0 et regardons le code de 
box: :dump(), 
solid object: :dump() et solid box: :dump() : 


Listing 3.95 : MSVC 2008 avec optimisation /ObO 


?dump@box@@QAEXXZ PROC ; box: :dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+8] 
mov edx, DWORD PTR [ecx+4] 
push eax 
mov eax, DWORD PTR [ecx] 
push edx 
push eax 
‘this is a box. width=%d, height=%d, depth=%d', OaH, 00H 
push OFFSET ?? C@ OCMGDIKPHDFIQthis?5is?5box?4?5width?$DN?$CFd?0?57 
y height?$DN?$CFd@ 
call printf 
add esp, 16 
ret 0 
?dump@box@@QAEXXZ ENDP ; box: :dump 


Listing 3.96 : MSVC 2008 avec optimisation /ObO 


?dump@solid object@@QAEXXZ PROC ; solid object::dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx] 
push eax 
‘this is a solid object. density=%d', OaH 
push OFFSET ?? C@ OCC@KICFIINL@this?5is?5solid object?4?5density?$DN? 7 
S $CFd@ 
call printf 
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add esp, 8 
ret 0 
?dump@solid object@@QAEXXZ ENDP ; solid object: :dump 


Listing 3.97 : MSVC 2008 avec optimisation /ObO 


?dump@solid box@@QAEXXZ PROC ; solid box::dump, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+12] 
mov edx, DWORD PTR [ecx+8] 
push eax 
mov eax, DWORD PTR [ecx+4] 
mov ecx, DWORD PTR [ecx] 
push edx 
push eax 
push ecx 
‘this is a solid box. width=%d, height=%d, depth=%d, density=%d', OaH 
push OFFSET ?? C@ ODO@HNCNIHNN@this?5is?5solid box?4?5width?$DN?$CFd 
y ?0?5heiQ 
call printf 
add esp, 20 
ret 0 
?dump@solid box@@QAEXXZ ENDP ; solid box: :dump 


Donc, la disposition de la mémoire pour ces trois classes est: 


Classe box : 
offset | description 
+0x0 | width 
+0x4 | height 
+0x8 | depth 


Classe solid_object : 


offset | description 
+0x0 | density 


On peut dire que la disposition de la mémoire de la classe solid_box est unifiée : 


Classe solid_box : 


offset | description 


+0x0 | width 
+0x4 | height 
+0x8 | depth 


+0xC | density 


Le code des méthodes box: :get volume() et solid object::get density() est 
trivial: 


Listing 3.98 : MSVC 2008 avec optimisation /ObO 


?get_volume@box@@QAEHXZ PROC ; box: :get volume, COMDAT 
; this$ = ecx 
mov eax, DWORD PTR [ecx+8] 
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imul eax, DWORD PTR [ecx+4] 
imul eax, DWORD PTR [ecx] 
ret 0 
?get_volume@box@@QAEHXZ ENDP ; box: :get volume 


Listing 3.99 : MSVC 2008 avec optimisation /ObO 


?get_density@solid object@@QAEHXZ PROC ; solid object::get density, COMDAT 
; this$ = ecx 

mov eax, DWORD PTR [ecx] 

ret 0 
?get_density@solid object@@QAEHXZ ENDP ; solid object::get density 


Mais le code de la méthode solid box::get weight() est bien plus intéressant: 


Listing 3.100 : MSVC 2008 avec optimisation /ObO 


?get_weight@solid box@@QAEHXZ PROC ; solid box::get weight, COMDAT 
; this$ = ecx 
push esi 
mov esi, ecx 
push edi 
lea ecx, DWORD PTR [esi+12] 
call ?get density@solid object@@QAEHXZ ; solid object::get density 
mov ecx, esi 
mov edi, eax 
call ?get_volume@box@@QAEHXZ ; box::get volume 
imul eax, edi 
pop edi 
pop esi 
ret 0 
?get_weight@solid box@@QAEHXZ ENDP ; solid box: :get weight 


get weight() appelle juste deux méthodes, mais pour get volume() il passe sim- 
plement un pointeur sur this, et pour get density() il passe un pointeur sur this 
incrémenté de 12 (ou 0xC) octets, et ici, dans la disposition de la mémoire de la 
classe solid box, les champs de la classe solid object commencent. 


Ainsi, la méthode solid object::get density() croira qu'elle traite une classe 
solid object usuelle, et la méthode box::get volume() fonctionnera avec ses 
trois champs, croyant que c'est juste un objet usuel de la classe box. 


Ainsi, on peut dire, un objet d'une classe, qui hérite de plusieurs autres classes, est 
représenté en mémoire comme une classe unifiée, qui contient tous les champs 
hérités. Et chaque méthode héritée est appelée avec un pointeur sur la partie cor- 
respondante de la structure. 


Méthodes virtuelles 


Encode un exemple simple: 


#include <stdio.h> 
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class object 


public: 
int color; 
object() { y; 
object (int color) { this->color=color; }; 
virtual void dump() 


{ 
un 


printf ("color=%d\n", color); 


class box : public object 


t 


private: 
int width, height, depth; 

public: 
box(int color, int width, int height, int depth) 
1 


this->color=color; 
this->width=width; 
this->height=height; 
this->depth=depth; 
h 
void dump() 
1 
printf ("this is a box. color=%d, width=%d, height=%d, depth=%d 
y Mn", color, width, height, depth); 
h 


class sphere : public object 


{ 


int 


private: 
int radius; 
public: 
sphere(int color, int radius) 
{ 
this->color=color; 
this->radius=radius; 
}; 
void dump() 


printf ("this is sphere. color=%d, radius=%d\n", color, radius) 7 
S ; 
}; 
main() 


box b(1, 10, 20, 30); 
sphere s(2, 40); 
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object *ol=8b; 
object *o2=&s; 


o1->dump(); 

02->dump(); 

return 0; 
}; 


La classe object a une méthode virtuelle dump() qui est remplacée par celle de la 
classe héritant box et sphere. 


Si nous sommes dans un environnement ou le type de l'objet n'est pas connu, comme 
dans la fonction main() de l'exemple, oü la méthode virtuelle dump() est appelée, 
l'information à propos de son type doit étre stockée quelque part, afin d'étre capable 
d'appeler la bonne méthode virtuelle. 


Compilons-le dans MSVC 2008 avec les options /0x et /0b0, puis regardons le code 
de main(): 
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_s$ = -32 ; size 
= 20 


_b$ = -20 ; size 
main PROC 
sub esp, 32 
push 30 
push 20 
push 10 
push 1 
lea ecx, DWORD PTR _b$[esp+48] 
call ??@box@@QAE@HHHH@Z ; box::box 
push 40 
push 2 
lea ecx, DWORD PTR _s$[esp+40] 
call ??@sphere@@QAE@HH@Z ; sphere::sphere 
mov eax, DWORD PTR _b$[esp+32] 
mov edx, DWORD PTR [eax] 
lea ecx, DWORD PTR _b$[esp+32] 
call edx 
mov eax, DWORD PTR _s$[esp+32] 
mov edx, DWORD PTR [eax] 
lea ecx, DWORD PTR _s$[esp+32] 
call edx 
xor eax, eax 
add esp, 32 
ret 0 
main ENDP 


Un pointeur sur la fonction dump() est pris quelque part dans l'objet. Oü pourrions- 
nous stocker l'adresse de la nouvelle méthode? Seulement quelque part dans le 
constructeur: il n'y a pas d'autre endroit puisque rien d'autre n'est appelé dans la 
fonction main(). ?? 


29Vous pouvez en lire plus sur les pointeurs sur les fonctions dans la section afférente:(1.33 on 
page 495). 
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Regardons le code du constructeur de la classe box : 


??_RO?AVbox@@@8 DD FLAT:?? 7type info@@6B@ ; box `RTTI Type Descriptor' 
DD 00H 
DB '.?AVbox@@', OOH 


??_R1A@?0A@EA@box@@8 DD FLAT:?? RO?AVbox@@@8 ; box:: RTTI Base Class 
Descriptor at (0,-1,0,64)' 


DD 01H 

DD 00H 

DD OffffffffH 
DD 00H 

DD 040H 


DD FLAT:?? R3box@@8 


?? R2box@@8 DD FLAT:?? R1A@?0A@EA@box@@8 ; box:: RTTI Base Class Array' 
DD FLAT:?? R1A@?0A@EA@obj ect@@s 


?? R3box@@8 DD 00H ; box:: RTTI Class Hierarchy Descriptor' 
DD 00H 
DD 02H 
DD FLAT: ??_ R2box@@8 


??_R4box@@6B@ DD 00H ; box:: RTTI Complete Object Locator' 
DD 00H 
DD 00H 
DD FLAT: ??_RO?AVbox@@@s 
DD FLAT: ??_ R3box@@8 


??_7box@@6B@ DD FLAT:?? R4box@@6B@ ; box:: vftable' 
DD FLAT : ?dump@box@@UAEXXZ 


_color$ = 8 ; size = 
_width$ 12 ; size = 
_height$ = 16 ; size 
_depth$ = 20 ; size 
??Qbox@@QAE@HHHH@Z PROC ; box::box, COMDAT 
; this$ = ecx 

push esi 

mov esi, ecx 

call ??0objectegQAEQXZ ; object::object 

mov eax, DWORD PTR color$[esp] 

mov ecx, DWORD PTR width$[esp] 

mov edx, DWORD PTR _height$[esp] 

mov DWORD PTR [esi+4], eax 

mov eax, DWORD PTR depth$[esp] 

mov DWORD PTR [esi+16], eax 

mov DWORD PTR [esi], OFFSET ?? 7box@@6B@ 

mov DWORD PTR [esi+8], ecx 

mov DWORD PTR [esi+12], edx 

mov eax, esi 

pop esi 

ret 16 
??Qbox@@QAE@HHHH@Z ENDP ; box::box 


AS 
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Ici, nous avons une disposition de la mémoire légèrement différente: Le premier 
champ est un pointeur sur une table box: :* vftable' (le nom a été mis par le com- 
pilateur MSVC). 


Dans cette table nous voyons un lien sur une table nommée 
box: :*RTTI Complete Object Locator' et aussi un lien 
sur la méthode box: :dump(). 


Elles sont appelées table de méthodes virtuelles et RTTI??. La table de méthodes 
virtuelles a l'adresse des méthodes et la table RTTI contient l'information à propos 
des types. 


À propos, les tables RTTI sont utilisées lors de l'appel à dynamic cast et typeid en 
C++. Vous pouvez également voir ici le nom de la classe en chaîne de texte pur. 


Ainsi, une méthode de la classe de base object peut aussi appelé la méthode virtuelle 
object::dump(), qui, en fait, va appeler une méthode d'une classe héritée, puisque 
cette information est présente juste dans la structure de l'objet. 


Du temps CPU additionnel est requis pour faire la recherche dans ces tables et trou- 
ver l'adresse de la bonne méthode virtuelle, ainsi les méthodes virtuelles sont large- 
ment considérées comme légérement plus lentes que les méthodes normales. 


Dans le code généré par GCC, les tables RTTI sont construites légérement différem- 
ment. 


3.21.2 ostream 


Recommençons avec l'exemple «hello world», mais cette fois nous allons utiliser 
ostream : 


#include <iostream> 


int main() 


{ 
I 


std::cout << "Hello, world!\n"; 


Presque tous les livres sur C++ nous disent que l'opérateur << peut-étre défini (sur- 
chargé) pour tous les types. C'est ce qui est fait dans ostream. Nous voyons que 
operator<< est appelé pour ostream : 


Listing 3.101 : MSVC 2012 (listing réduit) 


$SG37112 DB 'Hello, world!', OaH, 00H 


main PROC 
push OFFSET $5G37112 
push OFFSET ?cout@std@@3V?$basic ostream@DU?$char traits@D@std@@@1@A ; 


std::cout 

call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic ostream@DU? 7 
y $char_traits@D@std@@@OGAAV10GPBD@Z ; 

std: :operator<<<std::char traits<char> > 
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add esp, 8 
xor eax, eax 
ret 0 

_main ENDP 


Modifions l'exemple: 


#include <iostream> 


int main() 


{ 
} 


std::cout << "Hello, " << "world!\n"; 


À nouveau, dans chaque livre sur C++ nous lisons que le résultat de chaque operator<< 
dans ostream est transmis au suivant. En effet: 


Listing 3.102 : MSVC 2012 


$SG37112 DB 'world!', OaH, 00H 
$SG37113 DB 'Hello, ', OOH 


main PROC 
push OFFSET $5G37113 ; ‘Hello, ' 
push OFFSET ?cout@std@@3V?$basic ostream@DU?$char traits@D@std@@@1@A ; 


std::cout 

call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic ostream@DU? 7 
y $char_traits@D@std@@@OGAAV10G@PBD@Z ; 

std: :operator<<<std::char traits<char> > 

add esp, 8 


push OFFSET $5G37112 ; 'world!' 

push eax ; résultat de l'exécution précédente de la fonction 
call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic ostream@DU? 7 

y $char_traits@D@std@@@OG@AAV1O@PBD@Z ; 

std: :operator<<<std::char traits<char> > 

add esp, 8 


xor eax, eax 
ret 0 
_main ENDP 


Si nous renommions la méthode operator<< en f(), ce code ressemblerait à ceci: 


f(f(std::cout, "Hello, "), "world!"); 


GCC génére presque le méme code que MSVC. 


3.21.3 Références 


En C++, les références sont aussi des pointeurs (3.23 on page 773), mais elles sont 
dites súre, car il est plus difficile de faire une erreur en les utilisant (C++11 8.3.2). 
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Par exemple, les références doivent toujours pointer sur un objet de type correspon- 
dant et ne peuvent pas étre NULL [Marshall Cline, C++ FAQ8.6]. 


Encore mieux que ca, les références ne peuvent étre changées, il est impossible de 
les faire pointer sur un autre objet (réassigner) [Marshall Cline, C++ FAQ8.51. 


Si nous essayons de modifier l'exemple avec des pointeurs (3.23 on page 773) pour 
utiliser des références a la place ... 


void f2 (int x, int y, int & sum, int € product) 
1 
sum-x-y ; 
productzx*y; 
$; 


...alors nous pouvons voir que le code compilé est simplement le méme que dans 
l'exemple avec les pointeurs (3.23 on page 773) : 


Listing 3.103 : MSVC 2010 avec optimisation 


_x$ = 8 ; size = 4 

_y$ = 12 ; size = 4 

_sum$ = 16 ; size = 4 

_product$ = 20 ; size = 4 

? f2@@YAXHHAAHO@Z PROC = f2 
mov ecx, DWORD PTR _y$[esp-4] 
mov eax, DWORD PTR x$[esp-4] 
lea edx, DWORD PTR [eax+ecx] 
imul eax, ecx 
mov ecx, DWORD PTR product$[esp-4] 
push esi 
mov esi, DWORD PTR sum$[esp] 
mov DWORD PTR [esi], edx 
mov DWORD PTR [ecx], eax 
pop esi 
ret 0 

? f2@@YAXHHAAHO@Z ENDP EZ 


(La raison pour laquelle les fonctions C++ ont des noms aussi étranges est expliquée 
ici: 3.21.1 on page 699.) 


De ce fait, les références C++ sont bien plus efficientes que les pointeurs usuels. 


3.21.4 STL 


N.B.: tous les exemples ici ont été testés uniquement en environnement 32-bit. x64 
non testé. 


std::string 


Internals 
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De nombreuses bibliothéques de chaínes [Dennis Yurichev, C/C++ programming lan- 
guage notes2.2] implémentent une structure qui contient un pointeur sur un buffer 
de chaîne, une variable qui contient toujours la longueur actuelle de la chaîne (ce 
qui est trés pratique pour de nombreuses fonctions: [Dennis Yurichev, C/C++ pro- 
gramming language notes2.2.1]) et une variable qui contient la taille actuelle du 
buffer. 


La chaîne dans le buffer est en général terminée par un zéro, afin de pouvoir passer 
un pointeur sur le buffer aux fonctions qui prennent une chaine C ASCIIZ standard. 


Il n'est pas précisé dans le standard C++ comment std::string doit étre implémentée, 
toutefois, elle l'est en général comme expliqué ci-dessus. 


La chaîne C++ n'est pas une classse (comme QString dansQt, par exemple) mais un 
template (basic string), ceci est fait afin de supporter différents types de caractéres: 
au moins char et wchar t. 


Donc, std::string est une classe avec char comme type de base. 


Et std::wstring est une classe avec wchar t comme type de base. 
MSVC 


L'implémentation de MSVC peut stocker le buffer en place au lieu d'utiliser un poin- 
teur sur un buffer (si la chaine est plus courte que 16 symboles). 


Ceci implique qu'une chaîne courte occupe au moins 16+4+4 = 24 octets en environ- 
nement 32-bit et au moins 16+8+8 = 32 octets dans un 64-bit, et si la chaine est plus 
longue que 16 caractères, nous devons ajouter la longueur de la chaîne elle-même. 


Listing 3.104 : exemple pour MSVC 


#include <string> 
#include <stdio.h> 


struct std string 


1 . 
union 
{ 
char buf[16]; 
char* ptr; 
} u; 
size t size; // AKA 'Mysize' dans MSVC 
size_t capacity; // AKA 'Myres' dans MSVC 
}; 
void dump_std_string(std::string s) 
{ 
struct std string *p=(struct std_string*)&s; 
printf ("[%s] size:%d capacity:%d\n", p->size>16 ? p-»u.ptr : p-»u.buf,7 
Y p->size, p->capacity); 
}; 


int main() 
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1 
std::string sl="a short string"; 
std::string s2-"a string longer than 16 bytes"; 
dump std string(s1); 
dump std string(s2); 
// cela fonctionne sans utiliser c str() 
printf ("%s\n", &s1); 
printf ("%s\n", s2); 
$; 


Presque tout est clair dans le code source. 

Quelques notes: 

Si la chaîne est plus petite que 16 symboles, il n'y a pas de buffer alloué sur le tas. 
Ceci est pratique car en pratique, beaucoup de chaines sont courtes. 


Il semble que les développeurs de Microsoft aient choisi 16 caractéres comme un 
bon compromis. 


On voit une chose trés importante à la fin de main() : nous n'utilisons pas la mé- 
thode c str(), néanmoins, si nous compilons et exécutons ce code, les deux chaines 
apparaitrons dans la console! 


C'est pourquoi ceci fonctionne. 


Dans le premier cas, la chaîne fait moins de 16 caractères et le buffer avec la chaîne 
se trouve au début de l'objet std::string (il peut-étre traité comme une structure). 
printf() traite le pointeur comme un pointeur sur un tableau de caractéres terminé 
par un 

0, donc ca fonctionne. 


L'affichage de la seconde chaine (de plus de 16 caractéres) est encore plus dan- 
gereux: c'est une erreur typique de programmeur (ou une typo) d'oublier d'écrire 
c str(). 


Ceci fonctionne car pour le moment un pointeur sur le buffer est situé au début de 
la structure. 


Ceci peut passer inapercu pendant un long moment, jusqu'à ce qu'une chaine plus 
longue apparaisse à un moment, alors le processus plantera. 


GCC 


L'implémentation de GCC de cette structure a une variable de plus—le compteur de 
références. 


Une chose intéressante est que dans GCC un pointeur sur une instance de std::string 
ne pointe pas au début de la structure, mais sur le pointeur du buffer. Dans /ibstdc++- 
v3\include\bits\basic_string.h nous pouvons lire que ca a été fait ainsi afin de faciliter 
le débogage: 
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* XA * * + 


The reason you want M data pointing to the character %array and 
not the Rep is so that the debugger can see the string 
contents. (Probably we should add a non-inline member to get 

the Rep for the debugger to use, so users can check the actual 
string length.) 


code source de basic string.h 


Considérons ceci dans notre exemple: 


Listing 3.105 : exemple pour GCC 


#include <string> 
#include <stdio.h> 


struct std string 


{ 


}; 


size t length; 
size t capacity; 
size t refcount; 


void dump std string(std::string s) 


t 


int 


}; 


char *pl=*(char**)&s; // GCC type checking workaround 

struct std string *p2=(struct std string*)(pl-sizeof(struct std string)” 
6); 

printf ("[%s] size:%d capacity:%d\n", pl, p2->length, p2-»capacity); 


main () 


std::string sl="a short string"; 
std::string s2="a string longer than 16 bytes"; 


dump std string(s1); 
dump std string(s2); 


// GCC type checking workaround: 
printf ("%s\n", *(char**)&s1); 
printf ("%s\n", *(char**)&s2); 


Il faut utiliser une astuce pour imiter l'erreur que nous avons vue avant car GCC a 
une vérification de type plus forte, cependant, printf() fonctionne ici également sans 
c str(). 


Un exemple plus avancé 


#include <string> 
#include <stdio.h> 
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int main() 

1 
std::string sl="Hello, "; 
std::string s2="world!\n"; 
std::string s3=s1+s2; 


printf ("%s\n", s3.c str()); 


Listing 3.106 : MSVC 2012 


$5G39512 DB ‘Hello, ', 00H 
$5G39514 DB 'world!', OaH, 00H 
$SG39581 DB '%s', OaH, OOH 


_s2$ = -72 ; size = 24 
_s3$ = -48 ; size = 24 
_s1$ = -24 ; size = 24 
_main PROC 

sub esp, 72 

push 7 


push OFFSET $SG39512 

lea ecx, DWORD PTR _s1$[esp+80] 

mov DWORD PTR s1$[esp+100], 15 

mov DWORD PTR s1$[esp+96], 0 

mov BYTE PTR s1$[esp+80], 0 

call ?assign@?$basic string@DU?$char traits@D@std@@V?, 
S $allocator@D@2@@std@@QAEAAV12@PBDI@Z ; 


std: :basic string<char,std::char traits<char>,std::allocator<char> >::assi 


push 7 

push OFFSET $SG39514 

lea ecx, DWORD PTR _s2$[esp+80] 

mov DWORD PTR _s2$[esp+100], 15 

mov DWORD PTR _s2$[esp+96], 0 

mov BYTE PTR _s2$[esp+80], 0 

call ?assign@?$basic string@DU?$char traits@D@std@@V?, 
S $allocator@D@2@@std@@QAEAAV12@PBDI@Z ; 


std: :basic string<char,std::char traits<char>,std::allocator<char> >::assi 


lea eax, DWORD PTR _s2$[esp+72] 

push eax 

lea eax, DWORD PTR _s1$[esp+76] 

push eax 

lea eax, DWORD PTR _s3$[esp+80] 

push eax 

call ??$?HDU?$char_traits@D@std@@V?$allocator@D@l@@std@@YA?AV? 7 


V $basic string@DU?$char traits@D@std@@V?$allocator@D@2@@0GABV10@0€Z ; 


std::operator+<char,std::char traits<char>,std::allocator<char> > 


; méthode c str() mise en ligne (inlined): 
cmp DWORD PTR _s3$[esp+104], 16 
lea eax, DWORD PTR _s3$[esp+84] 


gn 


gn 
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cmovae eax, DWORD PTR _s3$[esp+84] 


push eax 

push OFFSET $5G39581 
call printf 

add esp, 20 


cmp DWORD PTR _s3$[esp+92], 16 
jb SHORT $LN119@main 
push DWORD PTR _s3$[esp+72] 
call ??3@YAXPAX@Z ; opérateur delete 
add esp, 4 
$LN119@main: 
cmp DWORD PTR _s2$[esp+92], 16 
mov DWORD PTR _s3$[esp+92], 15 
mov DWORD PTR s3$[esp+88], 0 
mov BYTE PTR _s3$[esp+72], 0 
jb SHORT $LN151@main 
push DWORD PTR _s2$[esp+72] 
call ??3@YAXPAX@Z ; opérateur delete 
add esp, 4 
$LN151@main: 
cmp DWORD PTR s1$[esp+92], 16 
mov DWORD PTR _s2$[esp+92], 15 
mov DWORD PTR s2$[esp+88], 0 
mov BYTE PTR _s2$[esp+72], 0 
jb SHORT $LN195@main 
push DWORD PTR _s1$[esp+72] 
call ??3@YAXPAX@Z ; opérateur delete 
add esp, 4 
$LN195@main: 
xor eax, eax 
add esp, 72 
ret 0 
_main ENDP 


Le compilateur ne construit pas les chaines statiquement: il ne serait de toutes fa- 
cons pas possible si le buffer devait étre situer dans le tas. 


au lieu de ca, les chaines ASCIIZ sont stockées dans le segment de données, et plus 
tard, au lancement, avec l'aide de la méthode «assign », les chaines s1 et s2 sont 
construites. 


Veuillez noter qu'il n'y a pas d'appel à la méthode c str(), car le code est assez petit 
pour que le compilateur le mette en ligne ici: si la chaine est plus courte que 16 
caractéres, un pointeur sur le buffer est laissé dans EAX, autrement l'adresse du 
buffer de la chaîne située dans le tas est récupérée. 


Ensuite, nous voyons les appels aux 3 destructeurs, is sont appelés si la chaine fait 
plus de 16 caractéres: le buffer dans le tas doit étre libéré. Autrement, puisque les 
trois objets std::string sont stockés dans la pile, ils sont automatiquement libérés 
lorsque la fonction se termine. 


En conséquence, traiter des chaînes courtes est plus rapide, car il y a moins d'accès 
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au tas. 


Le code de GCC est encore plus simple (car la maniére de GCC, comme nous l'avons 
VU ci-dessus, est de ne pas stocker les chaînes courtes directement dans la struc- 


ture) : 
Listing 3.107 : GCC 4.8.1 
.LC0: 
.string "Hello, " 
.LC1: 
.string "world!\n" 
main: 
push ebp 
mov ebp, esp 
push edi 
push esi 
push ebx 
and esp, -16 
sub esp, 32 
lea ebx, [esp+28] 
lea edi, [esp+20] 
mov DWORD PTR [esp+8], ebx 
lea esi, [esp+24] 
mov DWORD PTR [esp+4], OFFSET FLAT: .LCO 
mov DWORD PTR [esp], edi 
call ZNSsCIEPKCRKSaICE 
mov DWORD PTR [esp+8], ebx 
mov DWORD PTR [esp+4], OFFSET FLAT: .LC1 
mov DWORD PTR [esp], esi 
call _ZNSsC1EPKcRKSaIcE 
mov DWORD PTR [esp+4], edi 
mov DWORD PTR [esp], ebx 
call _ZNSsC1ERKSs 
mov DWORD PTR [esp+4], esi 
mov DWORD PTR [esp], ebx 
call _ZNSs6appendERKSs 
; c str() mis en ligne (inlined): 
mov eax, DWORD PTR [esp+28] 
mov DWORD PTR [esp], eax 
call puts 
mov eax, DWORD PTR [esp+28] 
lea ebx, [esp+19] 
mov DWORD PTR [esp+4], ebx 


sub 


eax, 12 
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mov DWORD PTR [esp], eax 

call ZNSs4 Rep10 M disposeERKSaICE 
mov eax, DWORD PTR [esp+24] 

mov DWORD PTR [esp+4], ebx 

sub eax, 12 

mov DWORD PTR [esp], eax 

call ZNSs4 Rep10 M disposeERKSaICE 
mov eax, DWORD PTR [esp+20] 

mov DWORD PTR [esp+4], ebx 

sub eax, 12 

mov DWORD PTR [esp], eax 

call ZNSs4 Rep10 M disposeERKSaICE 
lea esp, [ebp-12] 

xor eax, eax 

pop ebx 

pop esi 

pop edi 

pop ebp 

ret 


On voit que ce n'est pas un pointeur sur l'objet qui est passé aux destructeurs, mais 
plutót une adresse 12 octets (ou 3 mots) avant, ¡.e., un pointeur sur le début réel de 
la structure. 


std::string comme une variable globale 
Les programmeurs C++ expérimentés savent que les des variables globales des 


types STL?! peuvent étre définis sans probléme. 
Oui, en effet: 


#include <stdio.h> 
#include <string> 


std::string s="a string"; 


int main() 


{ 
}; 


printf ("%s\n", s.c str()); 


Mais comment et où le constructeur de std::string sera appelé? 


En fait, cette variable sera initialisée avant le démarrage de main(). 


Listing 3.108 : MSVC 2012: voici comment une variable globale est construite et 
aussi comment sont destructeur est déclaré 


??  EsQQYAXXZ PROC 
push 8 
push OFFSET $SG39512 ; ‘a string’ 


31(C++) Standard Template Library 
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mov ecx, OFFSET ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A ; 


S 
call ?assign@?$basic string@DU?$char traits@D@std@@V?” 
y $allocator@D@2@@s td@@QAEAAV12@PBDI@Z ; 
std: :basic string<char,std::char traits<char>,std::allocator<char> >::assi 
push OFFSET ?? Fs@@YAXXZ ; "dynamic atexit destructor for 's'' 
call atexit 
pop ecx 
ret 0 
??  EsQQYAXXZ ENDP 


Listing 3.109 : MSVC 2012: ici une variable globale est utilisée dans main() 


$5G39512 DB 'a string', 00H 
$5G39519 DB '%s', OaH, OOH 


main PROC 
cmp DWORD PTR ?s@@3V?$basic string@DU?$char traitsqDastd(qQV? - 
y $allocator@D@2@@std@@A+20, 16 
mov eax, OFFSET ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A ; 


tmovae eax, DWORD PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A 
push eax 
push OFFSET $SG39519 ; '%s' 
call printf 
add esp, 8 
xor eax, eax 
ret 0 
_main ENDP 


Listing 3.110 : MSVC 2012: cette fonction destructeur est appelée avant exit 


??  FsQQYAXXZ PROC 
push ecx 
cmp DWORD PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A+20, 16 
jb SHORT $LN23@dynamic 
push esi 
mov esi, DWORD PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@s td@@A 
lea ecx, DWORD PTR $T2[esp+8] 
call ??0?$ Wrap allocaV?$allocator@D@std@@@std@@QAE@XxZ 
push OFFSET ?s@@3V?$basic string@DU?$char_traits@D@std@aV? ^ 
y $allocator@D@2@@std@@A ; 


lea ecx, DWORD PTR $T2[esp+12] 

call ??$destroy@PAD@?$ Wrap alloc@V?$allocator@D@std@@@std@@QAEXPAPAD@Z 
lea ecx, DWORD PTR $T1[esp+8] 

call ??0?$ Wrap_alloc@V?$allocator@D@std@@@std@@QAE@XZ 

push esi 

call ??3@YAXPAX@Z ; operator delete 

add esp, 4 


731 


pop esi 

$LN23@dynamic: 
mov DWORD PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A+20, 15 
mov DWORD PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A+16, 0 
mov BYTE PTR ?s@@3V?$basic string@DU?$char traits@D@std@@V?, 
y $allocator@D@2@@std@@A, 0 
pop ecx 
ret 0 

??  FsQQYAXXZ ENDP 


En fait, une fonction spéciale avec tous les constructeurs des variables globales est 
appelée depuis CRT, avant main(). 


Mieux que ca: avec l'aide de atexit() une autre fonction est enregistrée, qui contient 
des appels aux destructeurs de telles variables globales. 


GCC fonctionne comme ceci: 


Listing 3.111 : GCC 4.8.1 


main: 
push ebp 
mov ebp, esp 
and esp, -16 
sub esp, 16 
mov eax, DWORD PTR s 
mov DWORD PTR [esp], eax 
call puts 
xor eax, eax 
leave 
ret 
.LC0: 
.string "a string" 
GLOBAL sub I s: 
sub esp, 44 
lea eax, [esp+31] 
mov DWORD PTR [esp+8], eax 
mov DWORD PTR [esp+4], OFFSET FLAT: .LCO 
mov DWORD PTR [esp], OFFSET FLAT:s 
call ZNSsCIEPKCRKSaICE 
mov DWORD PTR [esp+8], OFFSET FLAT: dso handle 
mov DWORD PTR [esp+4], OFFSET FLAT:s 
mov DWORD PTR [esp], OFFSET FLAT: ZNSsDIEv 
call  cxa atexit 
add esp, 44 
ret 
.LFE645: 
.size GLOBAL sub I s, .- GLOBAL sub I s 
.section .init array,"aw" 
.align 4 
.long | GLOBAL sub Is 
.globl s 
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.bss 
.align 4 
.type s, @object 
.size s, 4 
St 
.zero 4 


.hidden | dso handle 


Mais il ne crée pas une fonction séparée pour cela, chaque destructeur est passé a 
atexit(), un par un. 


std::list 


Ceci est la célébre liste doublement chainée: chaque élément a deux pointeurs, un 
sur l'élément précédent et un sur le suivant. 


Ceci implique que l'empreinte mémoire est augmentés de 2 mots pour chaque élé- 
ment (8 octets dans un environnement 32-bit ou 16v octets en 64-bit). 


C++ STL ajoute juste les pointeurs «next » et «previous » à la structure existante du 
type que vous voulez unir dans une liste. 


Travaillons sur un exemple avec une simple structure de deux variables que nous 
voulons stocker dans une liste. 


Bien que le standard C++ ne dise pas comme l'implémenter, GCC et MSVC l'implé- 
mentent de maniére directe et similaire, donc il n'y a qu'un seul code source pour 
les deux: 


#include <stdio.h> 
#include <list> 
#include <iostream> 


struct a 
{ 
int x; 
int y; 
$; 
struct List node 
1 
struct List node* Next; 
struct List node* Prev; 
int x; 
int y; 
$; 
void dump_List_node (struct List_node *n) 
1 
printf ("ptr=0x%p  Next-0xs*p  Prev-0x*sp x=%d y=%d\n", 
n, n-» Next, n-> Prev, n->x, n-»y); 
$; 


void dump List vals (struct List node* n) 
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}; 


struct List node* current=n; 


for (;;) 
{ 
dump List node (current); 
current=current-> Next; 
if (current==n) // end 
break; 
}; 


void dump List val (unsigned int *a) 


{ 
#ifdef MSC VER 


// l'implémentation de GCC n'a pas le champ "size" 
printf (" Myhead=0x%p, Mysize=%d\n", a[0], a[1]); 


#endif 


}; 


dump List vals ((struct List node*)a[0]); 


int main() 


1 


std::list<struct a> l; 


printf ("* empty list:\n"); 
dump List val((unsigned int*) (void*)&l); 


struct a t1; 
tl.x-1; 

tl.y=2; 
l.push_front (t1); 
t1.x=3; 

t1.y=4; 
l.push_front (t1); 
t1.x=5; 

t1.y=6; 

l.push back (t1); 


printf ("* 3-elements list: An"); 
dump List val((unsigned int*) (void*)&l); 


std::list«struct a>::iterator tmp; 

printf ("node at .begin:\n"); 

tmp=l.begin(); 

dump List node ((struct List node *)*(void**)&tmp); 
printf ("node at .end:\n"); 

tmp=l.end(); 

dump List node ((struct List node *)*(void**)&tmp); 


printf ("* let's count from the beginning:\n"); 
std::list«struct a>::iterator it=l.begin(); 
printf ("1st element: %d %d\n", (*it).x, (*it).y); 
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ite; 
printf ("2nd element: %d %d\n", (*it).x, (*it).y); 
it++; 
printf ("3rd element: %d %d\n", (*it).x, (*it).y); 
ite; 


printf ("element at .end(): %d %d\n", (*it).x, (*it).y); 


printf ("* let's count from the end:\n"); 

std::list«struct a»::iterator it2-l.end(); 

printf ("element at .end(): %d %d\n", (*it2).x, (*it2).y); 
it2--; 

printf ("3rd element: %d %d\n", (*it2).x, (*it2).y); 


it2--; 
printf ("2nd element: %d %d\n", (*it2).x, (*it2).y); 
it2--; 


printf ("ist element: %d %d\n", (*it2).x, (*it2).y); 


printf ("removing last element...\n"); 
l.pop back(); 
dump List val((unsigned int*) (void*)&l); 


GCC 


Commencons avec GCC. 


Lorsque nous langons l'exemple, nous voyons un long dump, travaillons avec par 
morceaux. 


* empty list: 
ptr-0x0028fe90  Next-0x0028fe90  Prev-0x0028fe90 x=3 y=0 


Ici, nous voyons une liste vide. 


Bien que ce soit une liste vide, elle a un élément avec des données non initialisées 
(AKA dummy node) dans z et y. Les deux pointeurs «next» et «prev » pointeurs sur 
le noeud lui-méme: 
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list.begin() P list.end() 


X=déchets 
Y=déchets 


À ce moment, les itérateurs .begin et .end sont égaux l'un à l'autre. 


Si nous poussons 3 éléments, la liste interne sera: 


* 3-elements list: 


ptr=0x000349a0 Next=0x00034988 Prev=0x0028fe90 x=3 y=4 
ptr=0x00034988 Next=0x00034b40 Prev=0x000349a0 x=1 y=2 
ptr=0x00034b40  Next-0x0028fe90  Prev-0x00034988 x=5 y=6 
ptr=0x0028fe90 Next=0x000349a0 Prev=0x00034b40 x=5 y=6 


Le dernier élément est encore en 0x0028fe90, il ne sera pas déplacé avant l'élimi- 
nation de la liste. 


Il contient toujours des valeurs aléatoires dans x et y (5 et 6). Par coincidence, ces 
valeurs sont les méme que dans le dernier élément, mais ca ne signifie pas que ca 
soit significatif. 


Voici comment ces 3 éléments sont stockés en mémoire: 


Variable 
std::list 


list.begin() list.end() 


736 


La variable l pointe toujours sur le premier noeud. 


Les itérateurs .begin() et .end() ne sont pas des variables, mais des fonctions, qui 
renvoient des pointeurs sur le noeud correspondant lorsqu'elle sont appelées. 


Avoir un élément fictif (AKA nœud sentinelle) est une pratique répandue dans l'im- 
plémentation des listes doublements chainées. 


Sans lui, de nombreuses opérations deviennent légérement plus complexes et de ce 
fait, plus lentes. 


L'itérateur est en fait juste un pointeur sur un noeud. list.begin() et list.end() retourne 
juste des pointeurs. 


node at .begin: 

ptr=0x000349a0  Next-0x00034988 Prev=0x0028fe90 x-3 y=4 
node at .end: 

ptr=0x0028fe90 Next=0x000349a0  Prev-0x00034b40 x=5 y=6 


Le fait que le dernier élément ait un pointeur sur le premier et le premier élément 
ait un pointeur sur le dernier nous rappelle les listes circulaires. 


Ceci est trés pratique ici: en ayant un pointeur sur le premier élément de la liste, i.e., 
ce qui est dans la variable 1, il est tres facile d’obtenir rapidement un pointeur sur le 
dernier, sans devoir traverser toute la liste. 


Insérer un élément à la fin de la liste est également rapide, grace à cette caractéris- 
tique. 


operator-- et operator++ mettent la valeur courante de l'itérateur à la valeur 
current node-»prev ou current node-»next. 


Les itérateurs inverses (.rbegin, .rend) fonctionne de la méme facon, mais à l'envers. 


operator* renvoie un pointeur sur le point dans la structure du noeud, oü la structure 
débute, i.e., un pointeur sur le premier élément de la structure (z). 


L'insertion et la suppression dans la liste sont triviaux: simplement allouer un nou- 
veau noeud (ou le désallouer) et mettre à jour les pointeurs afin qu'ils soient valides. 


C'est pourquoi un itérateur peut devenir invalide aprés la suppression d'un élément: 
il peut toujours pointer sur le noeud qui a été déjà désalloué. Ceci est aussi appelé 
un dangling pointer. 


Et bien súr, l'information sur le noeud libéré (sur lequel pointe toujours l'itérateur) 
ne peut plus étre utilisée. 


L'implémentation de GCC (à partir de 4.8.1) ne stocke plus la taille courante de la 
liste: ceci implique une méthode .size() lente: il doit traverser toute la liste pour 
compter les éléments, car il n'a pas d'autre moyen d'obtenir l'information. 


Ceci signifie que cette opération est en O(n), i.e., elle devient constamment plus 
lente lorsque la liste grandit. 


Listing 3.112 : GCC 4.8.1 -fno-inline-small-functions avec optimisation 


main proc near 
push ebp 
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mov 
push 
push 
and 
sub 
lea 
mov 
mov 
mov 
call 
mov 
call 
lea 
mov 
mov 
mov 
mov 
call 
std: 
mov 
mov 
mov 
mov 
call 
std:: 
mov 
mov 
mov 
call 
cmp 
jz 
mov 
mov 
mov 
mov 


ebp, esp 

esi 

ebx 

esp, OFFFFFFFOh 

esp, 20h 

ebx, [esp+10h] 

dword ptr [esp], offset s ; "* empty list:" 
[esp+10h], ebx 

[esp+14h], ebx 

puts 

[esp], ebx 

_Z13dump List valPj ; dump List val(uint *) 

esi, [esp+18h] 

[esp+4], esi 

[esp], ebx 

dword ptr [esp+18h], 1 ; X pour le nouvel élément 
dword ptr [esp+1Ch], 2 ; Y pour le nouvel élément 
_ZNSt4listIlaSaISO EE10push frontERKSO ; 


:list<a,std::allocator<a>>::push front(a const&) 


[esp+4], esi 

[esp], ebx 

dword ptr [esp+18h], 3 ; X pour le nouvel élément 
dword ptr [esp+1Ch], 4 ; Y pour le nouvel élément 
_ZNSt4listIlaSaISO EE10push frontERKSO ; 
list<a,std::allocator<a>>: :push_front(a const&) 
dword ptr [esp], 10h 

dword ptr [esp+18h], 5 ; X pour le nouvel élément 
dword ptr [esp+1Ch], 6 ; Y pour le nouvel élément 
_Znwj ; opérateur new(uint) 

eax, OFFFFFFF8h 

short loc 80002A6 

ecx, [esp+1Ch] 

edx, [esp+18h] 

[eax+0Ch], ecx 

[eax+8], edx 


loc 80002A6: ; CODE XREF: main+86 


mov 
mov 
call 
stds 
mov 
call 
mov 
call 
mov 
call 
mov 
mov 
call 
mov 
call 
mov 
call 


[esp+4], ebx 

[esp], eax 

_ZNSt8 detaill5 List node base7 M hookEPSO ; 

_ detail:: List node base:: M hook(std:: detail:: List node base*) 
dword ptr [esp], offset a3ElementsList ; "* 3-elements list:" 
puts 

[esp], ebx 

_Z13dump List valPj ; dump List val(uint *) 

dword ptr [esp], offset aNodeAt begin ; "node at .begin:" 
puts 

eax, [esp+10h] 

[esp], eax 

_Z14dump List nodeP9List node ; dump List node(List node *) 
dword ptr [esp], offset aNodeAt end ; "node at .end:" 

puts 

[esp], ebx 

_Z14dump List nodeP9List node ; dump List node(List node *) 
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mov dword ptr [esp], offset aLetSCountFromT ; "* let's count from the 
beginning:" 

call puts 

mov esi, [esp+10h] 

mov eax, [esi+0Ch] 

mov [esp+0Ch], eax 

mov eax, [esi+8] 

mov dword ptr [esp+4], offset alstElementDD ; "1st element: %d %d\n" 
mov dword ptr [esp], 1 

mov [esp+8], eax 

call  printf chk 

mov esi, [esi] ; operator++: get ->next pointer 

mov eax, [esi+0Ch] 

mov [esp+0Ch], eax 

mov eax, [esi+8] 

mov dword ptr [esp+4], offset a2ndElementDD ; "2nd element: %d %d\n" 
mov dword ptr [esp], 1 

mov [esp+8], eax 

call  printf chk 

mov esi, [esi] ; operator++: get ->next pointer 

mov eax, [esi+0Ch] 

mov [esp+0Ch], eax 

mov eax, [esi+8] 

mov dword ptr [esp+4], offset a3rdElementDD ; "3rd element: %d %d\n" 
mov dword ptr [esp], 1 

mov [esp+8], eax 

call  printf chk 

mov eax, [esi] ; operator++: get ->next pointer 

mov edx, [eax+0Ch] 

mov [esp+0Ch], edx 

mov eax, [eax+8] 

mov dword ptr [esp+4], offset aElementAt endD ; 


"element at .end(): %d %d\n" 
mov dword ptr [esp], 1 


mov [esp+8], eax 
call  printf chk 
mov dword ptr [esp], offset aLetSCountFro 0 ; "* let's count from the 


end:" 

call puts 

mov eax, [esp+1Ch] 

mov dword ptr [esp+4], offset aElementAt endD ; 


"element at .end(): %d %d\n" 
mov dword ptr [esp], 1 


mov [esp+0Ch], eax 

mov eax, [esp+18h] 

mov [esp+8], eax 

call  printf chk 

mov esi, [esp+14h] 

mov eax, [esi+0Ch] 

mov [esp+0Ch], eax 

mov eax, [esi+8] 

mov dword ptr [esp+4], offset a3rdElementDD ; "3rd element: %d %d\n" 
mov dword ptr [esp], 1 
mov [esp+8], eax 
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call 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
call 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
call 
mov 
call 
mov 
mov 
call 
std:: 
mov 
call 
mov 
call 


. printf chk 

esi, [esi+4] ; operator-- 
eax, [esi+0Ch] 

[esp+0Ch], eax 

eax, [esi+8] 

dword ptr [esp+4], offset 
dword ptr [esp], 1 
[esp+8], eax 

. printf chk 

eax, [esi+4] ; operator-- 
edx, [eax+0Ch] 

[esp+0Ch], edx 

eax, [eax+8] 

dword ptr [esp+4], offset 
dword ptr [esp], 1 
[esp+8], eax 

. printf chk 

dword ptr [esp], offset aRemovingLastEl ; 
puts 

esi, [esp+14h] 

[esp], esi 


a2ndElementDD ; 


, 


alstElementDD ; 


, 


detail:: List node base:: 
[esp], esi ; void * 
_ZdlPv ; operator delete(void *) 
[esp], ebx 
 Z13dump List valPj 
mov [esp], ebx 
call ZNSt10 List basellaSaISO EE8 M clearEv ; 
std:: List base<a,std::allocator<a>>:: 
lea esp, [ebp-8] 
xor eax, eax 
pop ebx 
pop esi 
pop ebp 
retn 
main endp 


get ->prev pointer 


"2nd element: %d %d\n" 


get ->prev pointer 


"Ist element: %d %d\n" 


"removing last element..." 


ZNSt8 detaill5 List node base9 M unhookEv ; 
M unhook(void) 


; dump List val(uint *) 


M clear(void) 


Listing 3.113 : La sortie compléte 


* empty list: 


ptr-0x0028fe90  Next-0x0028fe90  Prev-0x0028fe90 x=3 y=0 
* 3-elements list: 

ptr=0x000349a0  Next-0x00034988 Prev=0x0028fe90 x-3 y=4 
ptr=0x00034988  Next-0x00034b40 Prev=0x000349a0 x=1 y=2 
ptr=0x00034b40  Next-0x0028fe90  Prev-0x00034988 x=5 y=6 
ptr=0x0028fe90  Next-0x000349a0  Prev-0x00034b40 x=5 y=6 
node at .begin: 

ptr=0x000349a0  Next-0x00034988 Prev=0x0028fe90 x=3 y=4 
node at .end: 

ptr=0x0028fe90 Next=0x000349a0  Prev-0x00034b40 x=5 y=6 


* let's count from the beginning: 
lst element: 3 4 
2nd element: 1 2 
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3rd element: 5 6 

element at .end(): 5 6 

* let's count from the end: 

element at .end(): 5 6 

3rd element: 5 6 

2nd element: 1 2 

lst element: 3 4 

removing last element... 

ptr-0x000349a0 Next=0x00034988 Prev=0x0028fe90 x23 y=4 
ptr=0x00034988 Next=0x0028fe90 Prev=0x000349a0 x=1 y=2 
ptr=0x0028fe90 Next=0x000349a0 Prev=0x00034988 x=5 y=6 


MSVC 


L'implémentation de MSVC (2012) est la méme, mais elle stocke aussi la taille cou- 
rante de la liste. 


Ceci implique que la méthode .size() est trés rapide (O(1)) : elle doit juste lire une 
valeur depuis la mémoire. 


D'un autre cóté, la variable size doit étre mise à jour à chaque insertion/suppression. 


L'implémentation de MSVC est aussi légérement différente dans la facon dont elle 
arrange les noeuds: 


Variable 
std::list 


list.end() list.begin() 


Eee ES 
be | 
Lp X=3eme élé- 

Y=3eme élé- 


GCC a son élément fictif à la fin de la liste, tandis que MSVC l'a au début. 


EN 


Listing 3.114 : MSVC 2012 avec optimisation /Fa2.asm /GS- /Ob1 


_1$ = -16 ; size = 8 
_t1$ = -8 ; size = 8 
_main PROC 

sub esp, 16 


push ebx 
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push esi 

push edi 

push 0 

push 0 

lea ecx, DWORD PTR _1$[esp+36] 

mov DWORD PTR 1$[esp+40], 0 

; allocate first garbage element 

call ? Buynode0@?$ List _alloc@$0A@U?$ List base types@Ua@@V? 7 
VS $allocator@Ua@@@s td@@@std@@a@std@@QAEPAU? 7 

& $_List_node@Ua@@PAX@2@PAU32@0@Z ; 

std:: List alloc<0,std:: List base types<a,std::allocator<a> > >:: Buynode 
mov edi, DWORD PTR imp printf 

mov ebx, eax 

push OFFSET $5G40685 ; '* empty list:' 

mov DWORD PTR _l$[esp+32], ebx 

call edi ; printf 

lea eax, DWORD PTR _1$[esp+32] 

push eax 

call ?dump List _val@@YAXPAI@Z ; dump List val 

mov esi, DWORD PTR [ebx] 

add esp, 8 

lea eax, DWORD PTR t1$[esp+28] 

push eax 

push DWORD PTR [esi+4] 

lea ecx, DWORD PTR _1$[esp+36] 

push esi 

mov DWORD PTR t1$[esp+40], 1 ; data for a new node 
mov DWORD PTR t1$[esp+44], 2 ; data for a new node 
; allocate new node 

call ??$ Buynode@ABUa@@e@?$ List buy@Ua@@V?, 

& $allocator@Ua@@@s td@@@s t d@@QAEPAU? 7 

& $_List_node@Ua@@PAX@1@PAU21@0ABUa@@@Z ; 

std:: List buy<a,std::allocator<a> >:: Buynode<a const > 
mov DWORD PTR [esi+4], eax 

mov ecx, DWORD PTR [eax+4] 

mov DWORD PTR t1$[esp+28], 3 ; data for a new node 
mov DWORD PTR [ecx], eax 

mov esi, DWORD PTR [ebx] 

lea eax, DWORD PTR _t1$[esp+28] 

push eax 

push DWORD PTR [esi+4] 

lea ecx, DWORD PTR _1$[esp+36] 

push esi 

mov DWORD PTR t1$[esp+44], 4 ; data for a new node 
; allocate new node 

call ??$ BuynodeGABUa@@@?$ List _buy@Ua@@V?, 

y $allocator@Ua@@@s td@@@s t d@@QAEPAU? > 

s $ _List_node@Ua@@PAX@1@PAU21@0ABUa@@@Z ; 

std:: List buy<a,std: :allocator<a> >:: Buynode<a const > 
mov DWORD PTR [esi+4], eax 

mov ecx, DWORD PTR [eax+4] 

mov DWORD PTR t1$[esp+28], 5 ; data for a new node 
mov DWORD PTR [ecx], eax 

lea eax, DWORD PTR _t1$[esp+28] 
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push eax 

push DWORD PTR [ebx+4] 

lea ecx, DWORD PTR _1$[esp+36] 

push ebx 

mov DWORD PTR ti$[esp+44], 6 ; data for a new node 

; allocate new node 

call ??$ Buynode@ABUa@@@?$ List buyQgUaQgQV? 7 

y $allocator@Ua@@@s td@@@s t d@@QAEPAU? 7 

& $_List_node@Ua@@PAX@1@PAU21@0ABUa@@@Z ; 

std:: List buy<a,std: :allocator<a> »:: Buynode<a const &> 
mov DWORD PTR [ebx+4], eax 

mov ecx, DWORD PTR [eax+4] 

push OFFSET $SG40689 ; '* 3-elements list:' 

mov DWORD PTR _l$[esp+36], 3 

mov DWORD PTR [ecx], eax 

call edi ; printf 

lea eax, DWORD PTR _1$[esp+32] 

push eax 

call ?dump List val@@YAXPAI@Z ; dump List val 

push OFFSET $SG40831 ; ‘node at .begin:' 

call edi ; printf 

push DWORD PTR [ebx] ; get next field of node "l" variable points to 
call ?dump List node@@YAXPAUList node@@@Z ; dump List node 
push OFFSET $SG40835 ; ‘node at .end:' 

call edi ; printf 

push ebx ; pointer to the node "l" variable points to! 
call ?dump List node@@YAXPAUList node@@@Z ; dump List node 
push OFFSET $5G40839 ; '* let''s count from the begin: ' 
call edi ; printf 

mov esi, DWORD PTR [ebx] ; operator++: get ->next pointer 
push DWORD PTR [esi+12] 

push DWORD PTR [esi+8] 

push OFFSET $SG40846 ; ‘lst element: %d %d' 

call edi ; printf 

mov esi, DWORD PTR [esi] ; operator++: get ->next pointer 
push DWORD PTR [esi+12] 

push DWORD PTR [esi+8] 

push OFFSET $SG40848 ; '2nd element: %d %d' 

call edi ; printf 

mov esi, DWORD PTR [esi] ; operator++: get ->next pointer 
push DWORD PTR [esi+12] 

push DWORD PTR [esi+8] 

push OFFSET $SG40850 ; ‘3rd element: %d %d' 

call edi ; printf 

mov eax, DWORD PTR [esi] ; operator++: get ->next pointer 
add esp, 64 

push DWORD PTR [eax+12] 

push DWORD PTR [eax+8] 

push OFFSET $SG40852 ; ‘element at .end(): %d %d' 

call edi ; printf 

push OFFSET $SG40853 ; '* let''s count from the end:' 

call edi ; printf 


push DWORD PTR [ebx+12] ; use x and y fields from the node "l" variable 


points to 
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push DWORD PTR [ebx+8] 

push OFFSET $SG40860 ; ‘element at .end(): %d 
call edi ; printf 

mov esi, DWORD PTR [ebx+4] ; operator--: get 
push DWORD PTR [esi+12] 

push DWORD PTR [esi+8] 

push OFFSET $SG40862 ; '3rd element: %d %d' 
call edi ; printf 

mov esi, DWORD PTR [esi+4] ; operator--: get 
push DWORD PTR [esi+12] 

push DWORD PTR [esi+8] 

push OFFSET $SG40864 ; '2nd element: %d %d' 
call edi ; printf 

mov eax, DWORD PTR [esi+4] ; operator--: get 
push DWORD PTR [eax+12] 

push DWORD PTR [eax+8] 

push OFFSET $SG40866 ; ‘lst element: %d %d' 
call edi ; printf 

add esp, 64 


push OFFSET $SG40867 ; ‘removing last element... 


call edi ; printf 
mov edx, DWORD PTR [ebx+4] 
add esp, 4 


; prev=next? 

; it is the only element, garbage one? 
; if yes, do not delete it! 

cmp edx, ebx 

je SHORT $LN349@main 

mov ecx, DWORD PTR [edx+4] 

mov eax, DWORD PTR [edx] 

mov DWORD PTR [ecx], eax 

mov ecx, DWORD PTR [edx] 

mov eax, DWORD PTR [edx+4] 

push edx 

mov DWORD PTR [ecx+4], eax 

call ??3@YAXPAX@Z ; operator delete 


add esp, 4 

mov DWORD PTR _l$[esp+32], 2 
$LN349@main: 

lea eax, DWORD PTR _1$[esp+28] 

push eax 


call ?dump List val@@YAXPAI@Z ; dump List val 
mov eax, DWORD PTR [ebx] 

add esp, 4 

mov DWORD PTR [ebx], ebx 

mov DWORD PTR [ebx+4], ebx 

cmp eax, ebx 


je SHORT $LN412@main 
$LL414@main: 

mov esi, DWORD PTR [eax] 

push eax 


call ??3@YAXPAX@Z ; operator delete 


%d ' 


-»prev pointer 


-»prev pointer 


-»prev pointer 
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add esp, 4 

mov eax, esi 

cmp esi, ebx 

jne SHORT $LL414@main 


$LN412@main: 
push ebx 
call ??3@YAXPAX@Z ; operator delete 
add esp, 4 
xor eax, eax 
pop edi 
pop esi 
pop  ebx 
add esp, 16 
ret 0 

_main ENDP 


Contrairement à GCC, le code de MSVC alloue l'élément fictif au début de la fonction 
avec l'aide de la fonction «Buynode », qui est aussi utilisée pour allouer le reste des 
noeuds (le code de GCC alloue le premier élément dans la pile locale). 


Listing 3.115 : La sortie compléte 


* empty list: 

_Myhead=0x003CC258, Mysize=0 

ptr=0x003CC258 Next=0x003CC258 Prev=0x003CC258 x=6226002 y=4522072 
* 3-elements list: 

_Myhead=0x003CC258, Mysize=3 

ptr-0x003CC258 Next=0x003CC288 _Prev=0x003CC2A0 
ptr=0x003CC288 Next=0x003CC270 _Prev=0x003CC258 
ptr=0x003CC270 Next=0x003CC2A0 _Prev=0x003CC288 
ptr-0x003CC2A0 Next=0x003CC258 Prevz0x003CC270 
node at .begin: 

ptr=0x003CC288 Next=0x003CC270  Prevz0x003CC258 x23 y=4 

node at .end: 

ptr=0x003CC258 Next=0x003CC288  Prevz0x003CC2A0 x=6226002 y=4522072 
* let's count from the beginning: 

lst element: 3 4 

2nd element: 1 2 

3rd element: 5 6 

element at .end(): 6226002 4522072 

* let's count from the end: 

element at .end(): 6226002 4522072 

3rd element: 5 6 

2nd element: 1 2 

lst element: 3 4 

removing last element... 

_Myhead=0x003CC258, Mysize=2 

ptr=0x003CC258 Next=0x003CC288  Prevz0x003CC270 x=6226002 y=4522072 
ptr=0x003CC288 Next=0x003CC270  Prevz0x003CC258 x=3 y=4 
ptr=0x003CC270 Next=0x003CC258 Prev=0x003CC288 x=1 y=2 


xX X X X 
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C++11 std::forward_list 
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La méme chose que std: :list, mais simplement chainé, i.e., ayant seulement le champ 
«next» dans chaque noeud. 


Il a une empreinte mémoire plus faible, mais dons n'offre pas la possibilité de tra- 
verser la liste en arriére. 


std::vector 


Nous appelons std: : vector un wrapper sûr sur le tableau C PODT??. En interne il 
ressemble à std: :string (3.21.4 on page 722) : il a un pointeur sur le buffer alloué, 
un pointeur sur la fin du tableau, et un pointeur sur la fin du buffer alloué. 


Les éléments du tableau résident en mémoire adjacents les un aux autres, tout 
comme un tableau normal (1.26 on page 341). En C++11 il y a une nouvelle mé- 
thode appelée .data(), qui renvoie un pointeur sur le buffer, comme .c str() dans 
std::string. 

Le buffer alloué dans le tas peut étre plus large que le tableau lui-méme. 

Les implémentations de MSVC et GCC sont similaires, seul sont légérement différents 
le nom des champs de la structure??, donc il y a un seul code source qui fonctionne 


pour les deux compilateurs. Voici encore le code pseudo-C pour afficher la structure 
de std: :vector: 


#include <stdio.h> 
#include <vector> 
#include <algorithm> 
#include <functional> 


struct vector of ints 


1 
// noms MSVC: 
int *Myfirst; 
int *Mylast; 
int *Myend; 
// La structure GCC est la méme, mais les noms sont: 
M start, M finish, M end of storage 
}; 
void dump(struct vector of ints *in) 
1 
printf ("_Myfirst=%p, Mylast=%p, Myend=%p\n", in->Myfirst, in->Mylastv 
V , in->Myend) ; 
size t size=(in->Mylast-in->Myfirst) ; 
size t capacity=(in->Myend-in->Myfirst) ; 
printf ("size=%d, capacity=%d\n", size, capacity); 
for (size t i=0; i<size; i++) 
printf ("element %d: %d\n", i, in->Myfirst[i]); 
}; 


32(C++) Plain Old Data Type 
33GCC internals: http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01371. 
html 
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int main() 
1 

std: :vector<int> c; 

dump ((struct vector of ints*)(void*)&c); 

c.push back(1); 

dump ((struct vector of ints*)(void*)&c); 

c.push back(2); 

dump ((struct vector of ints*)(void*)&c); 

c.push back(3); 

dump ((struct vector of ints*)(void*)&c); 

c.push back(4); 

dump ((struct vector of ints*)(void*)&c); 

c.reserve (6); 

dump ((struct vector of ints*)(void*)&c); 

c.push back(5); 

dump ((struct vector of ints*)(void*)&c); 

c.push back(6); 

dump ((struct vector of ints*)(void*)&c); 

printf ("%d\n", c.at(5)); // avec vérifications de limites 

printf ("%d\n", c[8]); // operator[], sans vérifications de limites 


}; 


Voici la sortie de ce programme lorsqu'il est compilé dans MSVC: 


_Myfirst=00000000, Mylast=00000000, Myend=00000000 
size=0, capacity=0 

_Myfirst=0051CF48, Mylast=0051CF4C, Myend=0051CF4C 
size=1, capacity=1 

element 0: 1 

_Myfirst=0051CF58, Mylast=0051CF60, _Myend=0051CF60 
size=2, capacity=2 

element 0: 1 

element 1: 2 

_Myfirst=0051C278, Mylast=0051C284, Myend=0051C284 
size=3, capacity=3 

element 0: 1 

element 1: 2 

element 2: 3 

_Myfirst=0051C290, Mylast=0051C2A0, _Myend=0051C2A0 
size=4, capacity=4 

element 0: 1 

element 1: 2 

element 2: 3 

element 3: 4 

_Myfirst=0051B180, Mylast=0051B190, Myend=0051B198 
size=4, capacity=6 

element 0: 1 

element 1: 2 

element 2: 3 

element 3: 4 

_Myfirst=0051B180, Mylast=0051B194, Myend=0051B198 
size=5, capacity-6 

element 0: 1 

element 1: 2 
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element 2: 3 

element 3: 4 

element 4: 5 

_Myfirst=0051B180, Mylast=0051B198, Myend=0051B198 
size=6, capacity=6 

element 
element 
element 
element 
element 
element 
6 
6619158 
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On voit qu'il n'y a pas de buffer alloué lorsque main() débute. Aprés le premier appel 
à push back(), un buffer est alloué. Et puis, aprés chaque appel à push back(), la 
taille du tableau et la taille du buffer (capacity) sont augmentées. Mais l'adresse 
du buffer change aussi, car push back() ré-alloue le buffer dans le tas à chaque 
fois. C'est une opération coüteuse, c'est pourquoi il est trés important de prévoir 
la taille du tableau dans le futur et de lui réserver assez d'espace avec la méthode 
.reserve(). 


Le dernier nombre est du déchet: il n'y a pas d'élément du tableau à cet endroit, donc 
un nombre aléatoire est affiché. Ceci illustre le fait que operator[] de std: :vector 
ne vérifie pas si l'index est dans le limites du tableau. La méthode plus lente .at(), 
toutefois, fait cette vérification et envoie une exception std::out of range en cas 
d'erreur. 


Regardons le code: 


Listing 3.116 : MSVC 2012 /GS- /Ob1 


$SG52650 DB 
$SG52651 DB 


'%d', OaH, OOH 
'*d', OaH, 00H 
_this$ = -4 ; size = 4 
. Pos$ = 8 ; size = 4 
?at@?$vector@HV?$allocator@H@std@@@std@@QAFAAHI@Z PROC ; 
std: :vector<int,std::allocator<int> >::at, COMDAT 
; this$ = ecx 
push ebp 
mov ebp, esp 
push ecx 
mov DWORD PTR this$[ebp], ecx 
mov eax, DWORD PTR _this$[ebp] 
mov ecx, DWORD PTR _this$[ebp] 
mov edx, DWORD PTR [eax+4] 
sub edx, DWORD PTR [ecx] 
sar edx, 2 
cmp edx, DWORD PTR _ Pos$[ebp] 
ja SHORT $LN1@at 
push OFFSET ?? C@ OBMQNMJKDPPOQinvalid?5vector?$DMT?$DO?5subscript?$AAQ 
call DWORD PTR imp ? Xout of range@std@@YAXPBD@Z 
$LN1Gat : 
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mov 
mov 
mov 
lea 
$LN3@at : 
mov 
pop 
ret 


eax, DWORD PTR this$[ebp] 
ecx, DWORD PTR [eax] 

edx, DWORD PTR  Pos$[ebp] 
eax, DWORD PTR [ecx+edx*4] 


esp, ebp 
ebp 
4 


?at@?$vector@HV?$allocator@H@std@@@std@@QAFAAHI@Z ENDP ; 


std: :vector<int,std::allocator<int> >::at 
_c$ = -36 ; size = 12 
$T1 = -24 ; size = 4 
$122 -20 ; size = 4 
$13 = -16 ; size = 4 
$14 = -12 ; size = 4 
$15 = -8 ; size = 4 
$162 -4 ; size = 4 
main PROC 
push ebp 
mov ebp, esp 
sub esp, 36 
mov DWORD PTR c$[ebp], 0 ; Myfirst 
mov DWORD PTR c$[ebp+4], 0 ; Mylast 
mov DWORD PTR c$[ebp+8], 0 ; Myend 
lea eax, DWORD PTR _c$[ebp] 
push eax 
call ?dump@@YAXPAUvector_of_ints@@@Z ; dump 
add esp, 4 
mov DWORD PTR $T6[ebp], 1 
lea ecx, DWORD PTR $T6[ebp] 
push ecx 
lea ecx, DWORD PTR c$[ebp] 
call ?push_back@?$vector@HV?$al Locator@H@std@@@std@@QAEX$$QAH@Z ; 
std::vector«int,std::allocator«int» >::push back 
lea edx, DWORD PTR c$[ebp] 
push edx 
call ?dump@@YAXPAUvector of_ints@@@Z ; dump 
add esp, 4 
mov DWORD PTR $T5[ebp], 2 
lea eax, DWORD PTR $T5[ebp] 
push eax 
lea ecx, DWORD PTR c$[ebp] 
call ?push_back@?$vector@HV?$al Locator@H@std@@@std@@QAEX$$QAH@Z ; 
std::vector«int,std::allocator«int» >::push back 
lea ecx, DWORD PTR c$[ebp] 
push ecx 
call ?dump@@YAXPAUvector_of_ints@@@Z ; dump 
add esp, 4 
mov DWORD PTR $T4[ebp], 3 
lea edx, DWORD PTR $T4[ebp] 
push edx 
lea ecx, DWORD PTR c$[ebp] 
call ?push_back@?$vector@HV?$al locator@H@std@@@std@@QAEX$$QAH@Z ; 
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std:: 
lea 
push 
call 
add 
mov 
lea 
push 
lea 
call 
std: 
lea 
push 
call 
add 
push 
lea 
call 
std: 
lea 
push 
call 
add 
mov 
lea 
push 
lea 
call 
std: 
lea 
push 
call 
add 
mov 
lea 
push 
lea 
call 
std: 
lea 
push 
call 
add 


vector<int,std::allocator<int> >::push back 

eax, DWORD PTR c$[ebp] 

eax 

?dump@@YAXPAUvector of ints@@@Z ; dump 

esp, 4 

DWORD PTR $T3[ebp], 4 

ecx, DWORD PTR $T3[ebp] 

ecx 

ecx, DWORD PTR c$[ebp] 

?push_back@?$vector@HV?$al Locator@H@std@@@std@@QAEX$$QAH@Z ; 


:vector<int,std::allocator<int> >::push back 


edx, DWORD PTR c$[ebp] 

edx 

?dump@@YAXPAUvector_of ints@@@Z ; dump 

esp, 4 

6 

ecx, DWORD PTR c$[ebp] 
?reserve@?$vector@HV?$allocator@H@std@@@std@@QAEXIGZ ; 


:vector<int,std::allocator<int> >::reserve 


eax, DWORD PTR c$[ebp] 

eax 

?dump@@YAXPAUvector of ints@@@Z ; dump 

esp, 4 

DWORD PTR $T2[ebp], 5 

ecx, DWORD PTR $T2[ebp] 

ecx 

ecx, DWORD PTR c$[ebp] 

?push_back@?$vector@HV?$al locator@H@std@@@std@@QAEX$$QAH@Z ; 


:vector<int,std::allocator<int> >::push back 


edx, DWORD PTR c$[ebp] 

edx 

?dump@@YAXPAUvector of ints@@@Z ; dump 

esp, 4 

DWORD PTR $T1[ebp], 6 

eax, DWORD PTR $T1[ebp] 

eax 

ecx, DWORD PTR c$[ebp] 

?push_back@?$vector@HV?$al locator@H@std@@@std@@QAEX$$QAH@Z ; 


:vector<int,std::allocator<int> >::push back 


ecx, DWORD PTR c$[ebp] 

ecx 

?dump@@YAXPAUvector of ints@@@Z ; dump 
esp, 4 


push 5 


lea 
call 
std: 
mov 
push 
push 
call 
add 
mov 
shl 
mov 


ecx, DWORD PTR c$[ebp] 
?at@?$vector@HV?$allocator@H@std@@@std@@QAFAAHIGZ ; 


:vector<int,std::allocator<int> >::at 


edx, DWORD PTR [eax] 
edx 

OFFSET $SG52650 ; '%d' 
DWORD PTR imp printf 
esp, 
eax, 
eax, 
ecx, 


UN © 00 


WORD PTR c$[ebp] 
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mov edx, DWORD PTR [ecx+eax] 

push edx 

push OFFSET $SG52651 ; '%d' 

call DWORD PTR imp printf 

add esp, 8 

lea ecx, DWORD PTR c$[ebp] 

call ? Tidy@?$vector@HV?$allocator@H@std@@@std@@IAEXXZ ; 
std::vector«int,std::allocator«int» >:: Tidy 

xor eax, eax 

mov esp, ebp 


pop ebp 
ret 0 
main ENDP 


Nous voyons que la méthode .at() vérifie les limites et envoie une exception en cas 
d'erreur. Le nombre que le dernier appel à printf() affiche est pris de la mémoire, 
sans aucune vérification. 


On peut se demander pourquoi ne pas utiliser des variables comme «size » et «ca- 
pacity », comme c'est fait dans std::string. Probablement que c'est fait comme 
cela pour avoir une vérification des limites plus rapide. 


Le code que GCC génére est en général presque le méme, mais la méthode .at() 
est mise en ligne: 


Listing 3.117 : GCC 4.8.1 -fno-inline-small-functions -O1 


main proc near 
push ebp 
mov ebp, esp 
push edi 
push esi 
push ebx 
and esp, OFFFFFFFOh 
sub esp, 20h 
mov dword ptr [esp+14h], 0 
mov dword ptr [esp+18h], 0 
mov dword ptr [esp+1Ch], 0 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 1 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>::push back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 2 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
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mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>: :push back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 3 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>: :push_back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 4 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>: :push back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov ebx, [esp+14h] 
mov eax, [esp+1Ch] 
sub eax, ebx 
cmp eax, 17h 
ja short loc_80001CF 
mov edi, [esp+18h] 
sub edi, ebx 
sar edi, 2 
mov dword ptr [esp], 18h 
call Znwj ; operator new(uint) 
mov esi, eax 
test edi, edi 
jz short loc 80001AD 
lea eax, ds:0[edi*4] 


mov [esp+8], eax PEE 
mov [esp+4], ebx ; src 
mov [esp], esi ; dest 


call memmove 


loc 80001AD: ; CODE XREF: main+F8 
mov eax, [esp+14h] 
test eax, eax 
jz short loc 80001BD 
mov [esp], eax ; void * 
call ZdlPv ; operator delete(void *) 


loc 80001BD: ; CODE XREF: main+117 
mov [esp+14h], esi 
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lea eax, [esi+edi*4] 
mov [esp+18h], eax 
add esi, 18h 

mov [esp+1Ch], esi 


loc 80001CF: ; CODE XREF: main+DD 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 5 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>: :push back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov dword ptr [esp+10h], 6 
lea eax, [esp+10h] 
mov [esp+4], eax 
lea eax, [esp+14h] 
mov [esp], eax 
call ZNSt6vectorliSaliEE9push backERKi ; 
std: :vector<int,std::allocator<int>>: :push back(int  const&) 
lea eax, [esp+14h] 
mov [esp], eax 
call Z4dumpPl4vector of ints ; dump(vector of ints *) 
mov eax, [esp+14h] 
mov edx, [esp+18h] 
sub edx, eax 
cmp edx, 17h 
ja short loc 8000246 


mov dword ptr [esp], offset aVector m range ; "vector:: M range check" 
call ZSt20 throw out of rangePKc ; 
std:: throw out of range(char const*) 
loc 8000246: ; CODE XREF: main+19C 


mov eax, [eax+14h] 

mov [esp+8], eax 

mov dword ptr [esp+4], offset aD ; "%d\n" 
mov dword ptr [esp], 1 

call  printf chk 

mov eax, [esp+14h] 

mov eax, [eax+20h] 

mov [esp+8], eax 

mov dword ptr [esp+4], offset aD ; "%d\n" 
mov dword ptr [esp], 1 

call  printf chk 

mov eax, [esp+14h] 

test eax, eax 

jz short loc 80002AC 

mov [esp], eax ; void * 
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call ZdlPv ; Operator delete(void *) 
jmp short loc_80002AC 


mov ebx, eax 

mov edx, [esp+14h] 

test edx, edx 

jz short loc_80002A4 

mov [esp], edx ; void * 

call ZdlPv ; operator delete(void *) 


loc 80002A4: ; CODE XREF: main+1FE 
mov [esp], ebx 
call Unwind Resume 


loc 80002AC: ; CODE XREF: main+1EA 

; main+1F4 

mov eax, 0 

lea esp, [ebp-0Ch] 

pop ebx 

pop esi 

pop edi 

pop ebp 


locret 80002B8: ; DATA XREF: .eh frame:08000510 
; .eh frame:080005BC 
retn 
main endp 


.reserve() est aussi mise en ligne. Elle appelle new() si le buffer est trop petit pour 
la nouvelle taille, appelle memmove() pour copier le contenu du buffer et appelle 
delete() pour libérer l'ancien buffer. 


Regardons aussi ce que le programme affiche s'il est compilé avec GCC: 


_Myfirst=0x(nil), Mylast=0x(nil), _Myend=0x(nil) 
size=0, capacity=0 

_Myfirst=0x8257008, _Mylast=0x825700c, _Myend=0x825700c 
size=1, capacity=1 

element 0: 1 

_Myfirst=0x8257018, _Mylast=0x8257020, Myend=0x8257020 
size=2, capacity=2 

element 0: 1 

element 1: 2 

_Myfirst=0x8257028, _Mylast=0x8257034, Myend=0x8257038 
size=3, Capacity=4 

element 0: 1 

element 1: 2 

element 2: 3 

_Myfirst=0x8257028, Mylast=0x8257038, _Myend=0x8257038 
size=4, capacity=4 

element 0: 1 

element 1: 2 

element 2: 3 
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element 3: 4 

_Myfirst=0x8257040, Mylast=0x8257050, _Myend=0x8257058 
size=4, capacity=6 

element 0: 1 

element 1: 2 

element 2: 3 

element 3: 4 

_Myfirst=0x8257040, Mylast=0x8257054, Myend=0x8257058 
size-5, Capacity=6 


element 0: 1 
element 1: 2 
element 2: 3 
element 3: 4 
element 4: 


_Myfirst=0x8257040, Mylast=0x8257058, Myend=0x8257058 
size=6, capacity=6 

element 0: 

element 
element 
element 
element 
element 
6 

0 
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Nous repérons que la taille du buffer grossit d'une manière différente qu'avec MSVC. 


Une simple expérimentation montre que l'implémentation de MSVC augmente le 
buffer de ~50% à chaque fois qu'il a besoin d'étre augmenté, tandis que le code de 
GCC l'augmente de 100% à chaque fois, i.e., le double. 


std::map and std::set 


L'arbre binaire est une autre structure de données fondamentale. 


Comme son nom l'indique, c'est un arbre oü chaque noeud a au plus 2 liens sur un 
autre noeud. Chaque noeud a une clef et/ou un valeur: std::set fourni seulement 
une clef dans chaque noeud, std: :map fourni à la fois une clef et une valeur dans 
chaque noeud 


Les arbres binaire sont générallement la structure utilisée dans l'implémentation des 
dictionnaires de clef-valeurs ((AKA «tableaux associatifs »). 


Il y a au moins ces trois propriétés importante qu'un arbre binaire possède: 
* Toutes les clefs sont toujours stockées sous une forme triée. 


* Les clefs de tout type peuvent étre stockées facilement. Les algorithmes de 
l'arbre binaire ne sont pas conscients du type de clef, seule une fonction de 
comparaison de clef est nécessaire. 


* Trouver une clef particuliére est relativement rapide comparé aux listes chai- 
nées et tableaux. 
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Voici un exemple trés simple: stockons ces nombres dans un arbre binaire: 0, 1, 2, 
3, 5, 6, 9, 10, 11, 12, 20, 99, 100, 101, 107, 1001, 1010. 


Toutes les clefs qui sont plus petites que la valeur de la clef du noeud sont stockées 
du cóté gauche. 


Toutes les clefs qui sont plus grandes que la valeur de la clef du noeud sont stockées 
du cóté droit. 


Ainsi, l'algorithme de recherche est simple: si la valeur que vous cherchez est plus 
petite que la valeur de la clef du noeud courant: déplacez à gauche, si elle plus 
grande: déplacez à droite, stoppez si la valeur cherchée est égale à la valeur de la 
clef du noeud. 


C'est pourquoi l'algorithme de recherche peut chercher des nombres, des chaînes 
de texte, etc., tant que la fonction de comparaison de clef est fourni. 


Toutes les clefs ont des valeurs uniques. 


En ayant cela, il faut « log, n itérations pour trouver une clef dans un arbre binaire 
équilibré avec n clef. Ceci implique que « 10 itérations sont pour « 1000 keys, ou x 13 
itérations pour « 10000 clefs. 


Pas mal, mais l'arbre doit toujours étre équilibré pour cela: i.e., les clefs doivent 
étre distribuées uniformément à chaque niveaux. Les opérations d'insertion et de 
suppression font un peut de maintenance pour garder l'arbre dans un état équilibré. 


Il y a plusieurs algorithme d'équilibrage disponible, incluant l'arbre AVL et l'arbre 
red-black. 


La derniére étend chaque noeud avec une valeur de «couleur» opur simplifier le 
processus de rééquilibrage, de ce fait, chaque noeud peut étre rouge ou noir. 


À la fois les implémentations des templates std: :map et std: :set de GCC et MSVC 
utilisent les arbres red-black. 


std::set a seulement des clefs. std: :map est la version étendue de std: :set : ila 
aussi une valeur à chaque noeud. 
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MSVC 


#include «map» 
#include «set» 
#include <string> 
#include <iostream> 


// La structure n'est pas paquée! Chaque champ occupe 4 octets. 
struct tree_node 


{ 
struct tree_node *Left; 
struct tree_node *Parent; 
struct tree_node *Right; 
char Color; // 0 - Red, 1 - Black 
char Isnil; 
//std::pair Myval; 
unsigned int first; // appelé Myval dans std::set 
const char *second; // non présent dans std::set 
}; 
struct tree struct 
1 
struct tree node *Myhead; 
size t Mysize; 
}; 


void dump tree node (struct tree node *n, bool is set, bool traverse) 
1 
printf ("ptr=0x%p Left=0x%p Parent=0x%p Right=0x%p Color=%d Isnil=%d\n"” 
Y, 
n, n-»Left, n->Parent, n->Right, n->Color, n->Isnil); 
if (n->Isnil==0) 


1 
if (is set) 
printf ("first=%d\n", n->first); 
else 
printf ("first=%d second=[%s]\n", n->first, n->second); 
} 
if (traverse) 
{ 
if (n->Isnil==1) 
dump tree node (n->Parent, is set, true); 
else 
{ 
if (n->Left->Isnil==0) 
dump tree node (n->Left, is set, true); 
if (n->Right->Isnil==0) 
dump tree node (n->Right, is set, true); 
}; 
}; 


}; 
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const char* ALOT OF TABSZ"NENtENENENENENENENEN EA E" ; 


void dump as tree (int tabs, struct tree node *n, bool is set) 


{ 


}; 


if (is set) 

printf ("%d\n", n->first); 
else 

printf ("%d [%s]\n", n->first, n->second) ; 
if (n->Left->Isnil==0) 


1 
printf ("%.*sL------- ", tabs, ALOT OF TABS); 
dump as tree (tabs+1, n->Left, is set); 

$; 

if (n->Right->Isnil==0) 

1 
printf ("%.*sR------- ", tabs, ALOT OF TABS); 
dump as tree (tabs+1, n->Right, is set); 

}; 


void dump map and set(struct tree struct *m, bool is set) 


1 


int 


printf ("ptr=0x%p, Myhead=0x%p, Mysize=%d\n", m, m->Myhead, m->Mysize); 


dump tree node (m->Myhead, is set, true); 
printf ("As a tree:\n"); 

printf ("root----"); 

dump as tree (1, m->Myhead->Parent, is set); 


main() 
// map 
std::map<int, const char*> m; 


m[10]="ten"; 
m[20]="twenty"; 
m[3]="three"; 

m[101]="one hundred one"; 
m[100]2"one hundred"; 
m[12]2"twelve"; 

m[107]="one hundred seven"; 


m[0]="zero"; 
m[1]="one"; 
m[6]="six"; 
m[99]="ninety-nine"; 
m[5]="five"; 


m[11]="eleven"; 

m[1001]2"one thousand one"; 
m[1010]2"one thousand ten"; 
m[2]="two"; 

m[9]2"nine"; 

printf ("dumping m as map:\n"); 
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dump map and set ((struct tree struct *)(void*)&m, false); 


std::map<int, const char*>::iterator itl=m.begin(); 


printf ("m.begin():\n"); 


dump tree node ((struct tree node *)*(void**)&itl, false, false); 


itl=m.end(); 
printf ("m.end():\n"); 


dump tree node ((struct tree node *)*(void**)&itl, false, false); 


// set 


std::set<int> s; 
.insert(123); 

.insert(456); 

.insert(11); 
.insert(12); 
.insert(100); 
s.insert(1001); 


un un nn un un 


printf ("dumping s as set:\n"); 
dump map and set ((struct tree struct *)(void*)&s, true); 
std::set«int»::iterator it2=s.begin(); 


printf ("s.begin():\n"); 


dump tree node ((struct tree node *)*(void**)&it2, true, false); 


it2-s.end(); 
printf ("s.end():\n"); 


dump tree node ((struct tree node *)*(void**)&it2, true, false); 


Listing 3.118 : MSVC 2012 


dumping m as map: 


ptr=0x0020FE04, Myhead=0x005BB3A0, Mysize=17 


ptr=0x005BB3A0 Left=0x005BB4A0 
S Isnil=1 

ptr=0x005BB3C0 Left=0x005BB4C0 
y Isnil=0 

first=10 second=[ten] 

ptr=0x005BB4C0 Left=0x005BB4A0 
S Isnil=0 

first=1 second=[one] 

ptr=0x005BB4A0 Left=0x005BB3A0 
y Isnil=0 

first=0 second=[zero] 

ptr=0x005BB520 Left=0x005BB400 
y Isnil=0 

first=5 second=[five] 

ptr=0x005BB400 Left=0x005BB5A0 
S Isnil=0 

first=3 second=[three] 

ptr=0x005BB5A0 Left=0x005BB3A0 
S Isnil=0 

first=2 second=[two] 

ptr=0x005BB4E0 Left=0x005BB3A0 
y Isnil=0 


Parent=0x005BB3C0 


Parent=0x005BB3A0 


Parent=0x005BB3C0 


Parent=0x005BB4C0 


Parent=0x005BB4C0 


Parent=0x005BB520 


Parent=0x005BB400 


Parent=0x005BB520 


Right=0x005BB580 


Right=0x005BB440 


Right=0x005BB520 


Right=0x005BB3A0 


Right=0x005BB4E0 


Right=0x005BB3A0 


Right=0x005BB3A0 


Right=0x005BB5C0 


Color=1 


Color=1 


Color=1 


Color=1 


Color=0 


Color=1 


Color=0 


Color=1 


759 


first=6 second=[six] 

ptr=0x005BB5C0 Left=0x005BB3A0 Parent=0x005BB4E0 Right=0x005BB3A0 Color=0 2 
y Isnil=0 

first=9 second=[nine] 

ptr=0x005BB440 Left=0x005BB3E0 Parent=0x005BB3C0 Right=0x005BB480 Color=1 2 
y Isnil=0 

first=100 second=[one hundred] 

ptr=0x005BB3E0 Left=0x005BB460 Parent=0x005BB440 Right=0x005BB500 Color=0 2 
y Isnil=0 

first=20 second=[twenty] 

ptr=0x005BB460 Left=0x005BB540 Parent=0x005BB3E0 Right=0x005BB3A0 Color=1 2 
y Isnil=0 

first=12 second=[twelve] 

ptr=0x005BB540 Left=0x005BB3A0 Parent=0x005BB460 Right=0x005BB3A0 Color=0 7 
S Isnil=0 

first=11 second=[eleven] 

ptr=0x005BB500 Left=0x005BB3A0 Parent=0x005BB3E0 Right=0x005BB3A0 Color=1 2 
y Isnil=0 

first=99 second=[ninety-nine] 

ptr=0x005BB480 Left=0x005BB420 Parent=0x005BB440 Right=0x005BB560 Color=0 7 
y Isnil=0 

first=107 second=[one hundred seven] 

ptr=0x005BB420 Left=0x005BB3A0 Parent=0x005BB480 Right=0x005BB3A0 Color=1 2 
y Isnil=0 

first=101 second=[one hundred onel 

ptr=0x005BB560 Left=0x005BB3A0 Parent=0x005BB480 Right=0x005BB580 Color=1 2 
S Isnil=0 

first=1001 second=[one thousand one] 

ptr=0x005BB580 Left=0x005BB3A0 Parent=0x005BB560 Right=0x005BB3A0 Color=0 7 


y Isnil=0 
first=1010 second=[one thousand ten] 
As a tree: 
root----10 [ten] 
L------- 1 [one] 
L------- 9 [zero] 
R------- 5 [five] 
lem 3 [three] 
L------- 2 [two] 
R------- 6 [six] 
R------- 9 [nine] 
Rice 100 [one hundred] 
Lirio o 20 [twenty] 
esit Subtus 12 [twelve] 
Lite 11 [eleven] 
R------- 99 [ninety-nine] 
R------- 107 [one hundred seven] 
L------- 101 [one hundred one] 
R------- 1001 [one thousand one] 
R------- 1010 [one thousand ten] 
m.begin(): 
ptr=0x005BB4A0 Left=0x005BB3A0 Parent=0x005BB4C0 Right=0x005BB3A0 Color=1 2 
y Isnil=0 


first=0 second=[zero] 
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m.end(): 
ptr=0x005BB3A0 Left=0x005BB4A0 Parent=0x005BB3C0 Right=0x005BB580 Color=1 7 
S Isnil=1 


dumping s as set: 
ptr=0x0020FDFC, Myhead=0x005BB5E0, Mysize=6 
ptr=0x005BB5E0 Left=0x005BB640 Parent=0x005BB600 Right=0x005BB6A0 Color=1 7 


S Isnil=1 
ptr=0x005BB600 Left=0x005BB660 Parent=0x005BB5E0 Right=0x005BB620 Color=1 7 
y Isnil=0 
first=123 
ptr=0x005BB660 Left=0x005BB640 Parent=0x005BB600 Right=0x005BB680 Color=1 7 
y Isnil=0 
first=12 
ptr=0x005BB640 Left=0x005BB5E0 Parent=0x005BB660 Right=0x005BB5E0 Color=0 7 
y Isnil=0 
first=11 
ptr=0x005BB680 Left=0x005BB5E0 Parent=0x005BB660 Right=0x005BB5E0 Color=0 7 
y Isnil=0 
first=100 
ptr=0x005BB620 Left=0x005BB5E0 Parent=0x005BB600 Right=0x005BB6A0 Color=1 7 
y Isnil=0 
first=456 
ptr=0x005BB6A0 Left=0x005BB5E0 Parent=0x005BB620 Right=0x005BB5E0 Color=0 7 
y Isnil=0 
first=1001 
As a tree: 
root - - - -123 
L------- 12 
L------- 11 
R------- 100 
R------- 456 
R------- 1001 
s.begin(): 
ptr=0x005BB640 Left=0x005BB5E0 Parent=0x005BB660 Right=0x005BB5E0 Color=0 7 
y Isnil=0 
first=11 
s.end(): 
ptr=0x005BB5E0 Left=0x005BB640 Parent=0x005BB600 Right=0x005BB6A0 Color=1 7 
S Isnil=1 


La structure n'est pas paquée, donc chaque valeur char occupe 4 octets. 
std: :set 


[Cormen, Thomas H. and Leiserson, Charles E. and Rivest, Ronald L. and Stein, Clif- 
ford, Introduction to Algorithms, Third Edition, (2009)]. 


34 


GCC 


34http://www.ethoberon.ethz.ch/WirthPubl/AD. pdf 
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#include <stdio.h> 
#include <map> 
#include <set> 
#include <string> 
#include <iostream> 


struct map pair 


{ 
int key; 
const char *value; 

$; 

struct tree node 

1 
int M color; // 0 - Red, 1 - Black 
struct tree node *M parent; 
struct tree node *M left; 
struct tree node *M right; 

$; 

struct tree struct 

1 
int M key compare; 
struct tree node M header; 
size t M node count; 

$; 


void dump tree node (struct tree node *n, bool is set, bool traverse, bool 7 
y dump keys and values) 


1 
printf ("ptr=0x%p M left-0x*p M_parent=0x%p M right=0x%p M color=%d\n", 
n, n->M_left, n->M_parent, n->M_right, n->M_color); 
void *point_after_struct=((char*)n)+sizeof(struct tree node); 


if (dump keys and values) 


{ 
if (is set) 
printf ("key=%d\n", *(int*)point after struct); 
else 
1 
struct map_pair *p=(struct map_pair *)point_after_struct; 
printf ("key=%d value=[%s]\n", p->key, p->value); 
}; 
}; 


if (traverse==false) 
return; 


if (n->M left) 

dump tree node (n->M left, is set, traverse, dump keys and values); 
if (n->M right) 

dump tree node (n->M right, is set, traverse, dump keys and values)” 
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Fi 


+ 


const char* ALOT OF TABS="\t\t\t\t\t\t\t\t\t\ EN E" ; 


void dump as tree (int tabs, struct tree node *n, bool is set) 


{ 


y 


void *point_after_struct=((char*)n)+sizeof(struct tree_node); 


if (is_set) 
printf ("%d\n", *(int*)point_after_struct); 

else 

1 
struct map pair *p=(struct map pair *)point after struct; 
printf ("%d [%s]\n", p->key, p->value); 


} 

if (n->M left) 

1 
printf ("%.*sL------- ", tabs, ALOT_OF_TABS); 
dump_as_tree (tabs+1, n->M_left, is set); 

$; 

if (n->M_right) 

1 
printf ("%.*sR------- ", tabs, ALOT_OF_TABS); 
dump as tree (tabs+1, n->M right, is set); 

$; 


void dump map and set(struct tree struct *m, bool is set) 


{ 


int 


printf ("ptr=0x%p, M_key_compare=0x%x, M header=0x%p, M node count=%d\n” 
Lory 
m, m->M key compare, &m->M header, m->M_node count); 
dump tree node (m->M header.M parent, is set, true, true); 
printf ("As a tree:\n"); 
printf ("root----"); 
dump as tree (1, m->M header.M parent, is set); 


main() 
// map 


std::map<int, const char*» m; 


m[10]="ten"; 
m[20]="twenty"; 
m[3]="three"; 


m[101]="one hundred one"; 
m[100]="one hundred"; 
m[12]2"twelve"; 

m[107]="one hundred seven"; 
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m[0]="zero"; 

m[1]2"one"; 

m[6]="six"; 
m[99]="ninety-nine"; 
m[5]="five"; 
m[11]="eleven"; 
m[1001]="one thousand one"; 
m[1010]="one thousand ten"; 
m[2]2"two"; 

m[9]2"nine"; 


printf ("dumping m as map:\n"); 
dump map and set ((struct tree struct *)(void*)&m, false); 


std::map<int, const char*>::iterator itl=m.begin(); 

printf ("m.begin():\n"); 

dump tree node ((struct tree node *)*(void**)8it1, false, false, true); 
itl=m.end(); 

printf ("m.end():\n"); 

dump tree node ((struct tree node *)*(void**)&itl, false, false, false) 
Vg 


// set 


std::set«int» s; 
.insert(123); 
.insert(456); 
.insert(11); 
.insert(12); 
.insert(100); 

s.insert(1001); 

printf ("dumping s as set:\n"); 

dump map and set ((struct tree struct *)(void*)&s, true); 
std::set«int»::iterator it2=s.begin(); 

printf ("s.begin():\n"); 

dump tree node ((struct tree node *)*(void**)&it2, true, false, true); 
it2-s.end(); 

printf ("s.end():\n"); 

dump tree node ((struct tree node *)*(void**)&it2, true, false, false); 


un un un un nn 


Listing 3.119 : GCC 4.8.1 


dumping m as map: 

ptr=0x0028FE3C, M key compare=0x402b70, M_header=0x0028FE40, M node count” 
y =17 

ptr-0x007A4988 M_left=0x007A4C00 M parent=0x0028FE40 M right-0x007A4B80 7 
& M color=1 

key=10 value=[ten] 

ptr=0x007A4C00 M left-0x007AA4BEO M parent=0x007A4988 M_right=0x007A4C60 7 
4 M_color=1 

key=1 value=[one] 

ptr-0x007A4BEO M_left=0x00000000 M parent=0x007A4C00 M right-0x00000000 7 
y M color-1 
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key=0 value=[zero] 

ptr=0x007A4C60 M left=0x007A4B40 
«y M color=0 

key=5 value=[five] 

ptr=0x007A4B40 M_left=0x007A4CE0 
& M_color=1 

key=3 value=[three] 

ptr=0x007A4CE0 M left-0x00000000 
4 M color=0 

key=2 value=[two] 

ptr=0x007A4C20 M_left=0x00000000 
& M_color=1 

key=6 value=[six] 

ptr=0x007A4D00 M_left=0x00000000 
& M_color=0 

key=9 value-[nine] 

ptr=0x007A4B80 M_left=0x007A49A8 
4 M_color=1 

key=100 value=[one hundred] 

ptr=0x007A49A8 M_left=0x007A4BA0 
& M_color=0 

key=20 value=[twenty] 

ptr=0x007A4BA0 M left-0x007A4C80 
& M color=1 

key=12 value=[twelve] 

ptr=0x007A4C80 M left-0x00000000 
4 M color=0 

key=11 value=[eleven] 

ptr=0x007A4C40 M left-0x00000000 
& M color=1 

key=99 value=[ninety-nine] 

ptr=0x007A4BCO M_left=0x007A4B60 
4 M_color=0 


key=107 value=[one hundred seven] 


ptr-0x007A4B60 M_left=0x00000000 
& M_color=1 

key=101 value=[one hundred one] 

ptr=0x007A4CA0 M_left=0x00000000 
4 M_color=1 


key=1001 value=[one thousand one] 


ptr-0x007A4CCO M left-0x00000000 
vy M color-0 


key=1010 value-[one thousand ten] 


As a tree: 
root----10 [ten] 


M_parent=0x007A4C00 


M_parent=0x007A4C60 


M_parent=0x007A4B40 


M_parent=0x007A4C60 


M_parent=0x007A4C20 


M_parent=0x007A4988 


M_parent=0x007A4B80 


M_parent=0x007A49A8 


M_parent=0x007A4BA0 


M_parent=0x007A49A8 


M_parent=0x007A4B80 


M_parent=0x007A4BC0 


M_parent=0x007A4BC0 


M_parent=0x007A4CA0 


M_right=0x007A4C20 


M_right=0x00000000 


M_right=0x00000000 


M_right=0x007A4D00 


M_right=0x00000000 


M rightz0x007A4BCO 


M right-0x007A4C40 


M right-0x00000000 


M right-0x00000000 


M right-0x00000000 


M_right=0x007A4CA0 


M_right=0x00000000 


M_right=0x007A4CC0 


M_right=0x00000000 
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L------- 20 [twenty] 
L------- 12 [twelve] 
L------- 11 [eleven] 
R------- 99 [ninety-nine] 
R------- 107 [one hundred seven] 
L------- 101 [one hundred one] 
R------- 1001 [one thousand one] 
R------- 1010 [one thousand ten] 
m.begin(): 
ptr=0x007A4BE0 M_left=0x00000000 M parent=0x007A4C00 M right-0x00000000 7 
4 M color=1 
key=0 value=[zero] 
m.end(): 
ptr=0x0028FE40 M left-0x007A4BEO M parent-0x007A4988 M right-0x007A4CCO 7 
& M color=0 


dumping s as set: 

ptr=0x0028FE20, M_key_compare=0x8, M_header=0x0028FE24, M node count=6 

ptr-0x007A1E80 M_left=0x01D5D890 M parent-0x0028FE24 M right-0x01D5D850 7 
& M color=1 

key=123 

ptr=0x01D5D890 M_left=0x01D5D870 M parent=0x007A1E80 M right-0x01D5D8BO 7 
& M color=1 

key=12 

ptr=0x01D5D870 M_left=0x00000000 M parent=0x01D5D890 M right-0x00000000 7 
4 M_color=0 

key=11 

ptr=0x01D5D8B0 M_left=0x00000000 M parent=0x01D5D890 M right-0x00000000 7 
& M_color=0 

key=100 

ptr=0x01D5D850 M_left=0x00000000 M parent=0x007A1E80 M right-0x01D5D8DO 7 
4 M color=1 

key=456 

ptr=0x01D5D8D0 M_left=0x00000000 M parent=0x01D5D850 M right-0x00000000 7 
& M color=0 

key=1001 

As a tree: 

root - - - -123 


s.begin(): 

ptr=0x01D5D870 M_left=0x00000000 M parent-0x01D5D890 M right-0x00000000 7 
4 M color=0 

key-11 

s.end(): 

ptr=0x0028FE24 M left-0x01D5D870 M parent-0x007A1E80 M right-0x01D5D8DO 7 
y M color-0 
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Démo de rééquilibrage (GCC) 


Il y a aussi une démo nous montrant comment un arbre est rééquilibré aprés quelques 
insertions. 


Listing 3.120 : GCC 


#include <stdio.h> 
#include <map> 
#include <set> 
#include <string> 
#include <iostream> 


struct map pair 


1 
int key; 
const char *value; 

$; 

struct tree node 

1 
int M color; // 0 - Red, 1 - Black 
struct tree node *M parent; 
struct tree node *M left; 
struct tree node *M right; 

$; 

struct tree struct 

1 
int M key compare; 
struct tree node M header; 
size t M node count; 

$; 


const char* ALOT OF TABSZ"NENENENENENENENENEN EA E" ; 


void dump as tree (int tabs, struct tree node *n) 


{ 


void *point_after_struct=((char*)n)+sizeof(struct tree node); 
printf ("%d\n", *(int*)point after struct); 


if (n->M left) 

1 
printf ("%.*sL------- ", tabs, ALOT OF TABS); 
dump as tree (tabs+1, n->M left); 

}; 

if (n->M_right) 


35http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.1/stl_ tree 
8h- source.html 
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printf ("%.*sR------- ", tabs, ALOT_OF_TABS); 
dump_as_tree (tabs+1, n->M_right); 
$; 
$; 


void dump map and set(struct tree struct *m) 


printf ("root----"); 
dump as tree (1, m->M_header.M parent); 


int main() 


std::set<int> s; 

s.insert(123); 

s.insert(456); 

printf ("123, 456 has been inserted\n"); 
dump map and set ((struct tree struct *)(void*)&s); 
s.insert(11); 

s.insert(12); 

printf ("Xn"); 

printf ("11, 12 has been insertedin"); 
dump map and set ((struct tree struct *)(void*)&s); 
s.insert(100); 

s.insert(1001); 

printf ("Xn"); 

printf ("100, 1001 has been insertedin"); 
dump map and set ((struct tree struct *)(void*)&s); 
s.insert(667); 

s.insert(1); 

s.insert(4); 

s.insert(7); 

printf ("Xn"); 

printf ("667, 1, 4, 7 has been inserted ^n"); 
dump map and set ((struct tree struct *)(void*)&s); 
printf ("Xn"); 


Listing 3.121 : GCC 4.8.1 


123, 456 has been inserted 


root----123 
R------- 456 
11, 12 has been inserted 
root----123 
L------- 11 
R------- 12 
R------- 456 


100, 1001 has been inserted 
root ----123 
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ccs 11 
R------- 100 
R------- 456 
R------- 1001 
667, 1, 4, 7 has been inserted 
root----12 
less 4 
pesetas 1 
Rise 11 
asis 7 
R------- 123 
L------- 100 
R------- 667 
L------- 456 
R------- 1001 


3.21.5 Mémoire 


Vous pouvez parfois entendre de la part de programmeurs C++ «allouer la mémoire 
sur la pile» et/ou «allouer la mémoire sur le tas ». 


Allouer un objet sur la pile : 


void f() 
1 


Class o=Class(...); 


}; 


La mémoire de l'objet (ou de la structure) est allouée sur le pile, en utilisant un 
simple décalage de SP. La mémoire est allouée jusqu'à la sortie de la fonction, ou, 
plus précisément, à la fin du scope—SP est remis à son état (comme au début de 
la fonction) et le destructeur de Class est appelé. De la même manière, la mémoire 
allouée pour une structure en C est désallouée à la sortie de la fonction. 


Allouer un objet dans le tas : 


void f1() 
{ 


Class *o=new Class(...); 


void f2() 
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delete o; 


}; 


Ceci est la même chose que d'allouer de la mémoire pour une structure en utilisant 
un appel à malloc(). En fait, new en C++ est un wrapper pour malloc(), et delete 
est un wrapper pour free(). Puisque le bloc de mémoire a été allouée sur le tas, il 
doit être désalloué explicitement, en utilisant delete. Le destructeur de classe sera 
appelé automatiquement juste avant ce moment. 


Quelle méthode est la meilleure? L'allocation ¡sur la pile est très rapide, et bon pour 
les petits, à durée de vie courte objets, qui seront utilisés seulement dans la fonction 
courante. 


L'allocation sur le heap est plus lente, et meilleure pour des objets à longue durée 
de vie, qui seront utilisés dans plusieurs fonctions. Aussi, les objets alloués sur le tas 
sont sujets à la fuite de mémoire, car ils doivent être libérés explicitement, mais on 
peut oublier de le faire. 


De toutes façons, ceci est une affaire de goût. 


3.22 Index de tableau négatifs 


Il est possible d'accéder à l'espace avant un tableau en donnant un index négatif, 
e.g., array|-1]. 


3.22.1 Accéder à une chaine depuis la fin 


Python LP permet d'accéder aux tableaux depuis la fin. Par exemple, string[-1] ren- 
voie le dernier caractére, string[-2] renvoie le pénultiéme, etc. Difficile à croire, mais 
ceci est aussi possible en C/C++ : 


#include <string.h> 
#include <stdio.h> 


int main() 
{ 
char *s="Hello, world!"; 
char *s_end=s+strlen(s); 


printf ("last character: %c\n", s end[-1]); 
printf ("penultimate character: %c\n", s end[-2]); 
$; 


Ca fonctionne, mais s_end doit toujours avoir l'adresse du zéro en fin de la chaíne s. 
Si la taille de la chaine s est modifiée, s end doit étre modifié aussi. 


L'astuce est douteuse, mais, encore une fois, ceci est une démonstration d'indices 
négatifs. 
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3.22.2 Accéder à un bloc quelconque depuis la fin 


Rappelons d'abord pourquoi la pile grossit en arriére (1.9.1 on page 43). Il y a une 
sorte de bloc en mémoire et vous voulez y stocker à la fois le heap et la pile, sans 
savoir comment ils vont grossir pendant l'exécution. 


Vous pouvez mettre un pointeur de heap au début du bloc, puis vous mettez un 
pointeur de pile à la fin du bloc (heap + size of block), et vous pouvez accéder au 
n-iéme élément de la pile avec stack[-n]. Par exemple, stack[-1] pour le 1er élément, 
stack[-2] pour le 2nd, etc. 


Ceci fonctionnera de la méme façon que notre astuce d'accéder la chaîne depuis la 
fin. 
Vous pouvez facilement vérifier si les structures n'ont pas commencé à se recouvrir: 


il suffit d'étre sür que l'adresse du dernier élément dans le heap est plus bas que le 
dernier élément de la pile. 


Malheureusement, l'index -0 ne fonctionnera pas, puisque la représentation des 
nombres négatifs en complément à deux ne permet pas de zéro négatif. donc il 
ne peut pas étre distingué d'un zéro positif. 


Ceci est aussi mentionné dans "Transaction processing", Jim Gray, 1993, chapitre 
“The Tuple-Oriented File System", p. 755. 


3.22.3 Tableaux commencants à 1 


Fortran et Mathematica définissent le premier élément d'un tableau avec l'indice 
1, sans doute parce que c'est la tradition en mathématiques. D'autres LPs comme 
C/C++ le définisse avec l'indice O. Lequel est le meilleur? Edsger W. Dijkstra prétend 
que le dernier est le meilleur °°. 


Mais les programmeurs peuvent toujours avoir l'habitude aprés le Fortran, donc avec 
ce petit truc, il est possible d'accéder au premier élément en C/C++ en utilisant 
l'indice 1: 


#include <stdio.h> 


int main() 
{ 
int random value=0x11223344; 
unsigned char array[10]; 
int i; 
unsigned char *fakearray=&array[-1]; 


for (i=0; i«10; i++) 
array[i]=i; 


printf ("first element %d\n", fakearray[1]); 
printf ("second element %d\n", fakearray[2]); 
printf ("last element %d\n", fakearray[10]); 


36Voir https: //www.cs.utexas.edu/users/EWD/transcriptions/EWDO8xx/EWD831.html 


WO YOU 3 0) NJ F2 
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printf ("array[-1]=%02X, array[-2]=%02X, array[-3]=%02X, array” 
& [-4]=%02X\n", 


array[-1], 
array[-2], 
array[-3], 
array[-4]); 
h 
Listing 3.122 : MSVC 2010 sans optimisation 
$SG2751 DB 'first element %d', OaH, 00H 
$SG2752 DB ‘second element %d', OaH, 00H 
$SG2753 DB ‘last element %d', OaH, 00H 
$5G2754 DB 'array[-1]=%02X, array[-2]=%02X, array[-3]=%02X, array[-4' 
DB ']=%02X', OaH, 00H 
_fakearray$ = -24 ; taille = 4 
random value$ = -20 ; taille = 4 
_array$ = -16 ; taille = 10 
i$ = -4 ; taille = 4 
main PROC 
push ebp 
mov ebp, esp 
sub esp, 24 
mov DWORD PTR random value$[ebp], 287454020 ; 11223344H 
; définir fakearray[] un octet avant array[] 
lea eax, DWORD PTR array$[ebp] 
add eax, -1 ; eax=eax-1 
mov DWORD PTR _fakearray$[ebp], eax 
mov DWORD PTR i$[ebp], 0 
jmp SHORT $LN3@main 
; remplir array[] avec 0..9 
$LN2@main: 
mov ecx, DWORD PTR  i$[ebp] 
add ecx, 1 
mov DWORD PTR _i$lebp], ecx 
$LN3@main: 
cmp DWORD PTR i$[ebp], 10 
jge SHORT $LN1@main 
mov edx, DWORD PTR i$[ebp] 
mov al, BYTE PTR _i$[ebp] 
mov BYTE PTR _array$[ebp+edx], al 
jmp SHORT $LN2@main 
$LN1@main: 
mov ecx, DWORD PTR _fakearray$[ebp] 
; ecx=adresse de fakearray[0], ecx+1 est fakearray[1] ou array[0] 
movzx edx, BYTE PTR [ecx+1] 
push edx 
push OFFSET $SG2751 ; ‘first element %d' 
call _printf 
add esp, 8 
mov eax, DWORD PTR _fakearray$[ebp] 


; eax=adresse de fakearray[0], eax+2 est fakearray[2] ou array[1] 


movzx 


ecx, BYTE PTR [eax+2] 
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push ecx 

push OFFSET $5G2752 ; ‘second element %d' 
call _printf 

add esp, 8 

mov edx, DWORD PTR fakearray$[ebp] 


; edx=adresse de fakearray[0], edx+10 est fakearray[10] ou array[9] 
MOVZX eax, BYTE PTR [edx+10] 


push eax 

push OFFSET $SG2753 ; ‘last element %d' 
call _printf 

add esp, 8 


; soustrait 4, 3, 2 et 1 du pointeur sur array[0] afin de trouver les 
valeurs avant array[] 


lea ecx, DWORD PTR array$[ebp] 
movzx edx, BYTE PTR [ecx-4] 

push edx 

lea eax, DWORD PTR array$[ebp] 
movzx ecx, BYTE PTR [eax-3] 

push ecx 

lea edx, DWORD PTR array$[ebp] 
movzx eax, BYTE PTR [edx-2] 

push eax 

lea ecx, DWORD PTR array$[ebp] 
movzx edx, BYTE PTR [ecx-1] 

push edx 


push OFFSET $SG2754 ; 
'array[-1]=%02X, array[-2]=%02X, array[-3]=%02X, array[-4]=%02X" 


call _ printf 
add esp, 20 
xor eax, eax 
mov esp, ebp 
pop ebp 
ret 0 

main  ENDP 


Donc nous avons le tableau array[] de dix éléments, rempli avec les octets 0...9. 
Puis nous avons le pointeur fakearray[], qui pointe un octet avant array[]. 


fakearray[1] pointe exactement sur array[0]. Mais nous sommes toujours cu- 
rieux, qu'y a-t-il avant array[] ? Nous avons ajouté random value avant array[] et 
l'avons défini à 0x11223344. Le compilateur sans optimisation a alloué les variables 
dans l'ordre dans lequel elles sont déclarées, donc oui, la valeur 32-bit random value 
est juste avant le tableau. 


Nous le lancons, et: 


first element 0 

second element 1 

last element 9 

array[-1]=11, array[-2]=22, array[-3]=33, array[-4]=44 


Voici le fragment de pile que nous avons copier/coller depuis la fenêtre de pile d’Ol- 
lyDbg (avec les commentaires ajoutés par l'auteur) : 
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Listing 3.123 : MSVC 2010 sans optimisation 


Pile du CPU 

Address Value 
QO1DFBCC /001DFBD3 ; pointeur fakearray 
001DFBDO |11223344 ; random value 

001DFBD4 |03020100 ; 4 octets de array[] 

001DFBD8 |07060504 ; 4 octets de array[] 

001DFBDC |00CB0908 ; reste aléatoire + 2 dernier octets de array[] 
001DFBEO |0000000A ; dernière valeur de i aprés la fin de la boucle 
001DFBE4 |001DFC2C ; valeur de EBP sauvée 

001DFBE8 \00CB129D ; Adresse de Retour 


Le pointeur sur fakearray[] (0x001DFBD3) est en effet l'adresse de array[] dans 
la pile (0x001DFBD4), mais moins 1 octet. 


C'est un truc trés astucieux et douteux. Personne ne devrait l'utiliser dans du code 
de production mais comme démonstration, ca joue parfaitement son róle. 


3.23 Plus loin avec les pointeurs 


The way C handles pointers, for example, 
was a brilliant innovation; it solved a lot of 
problems that we had before in data 
structuring and made the programs look 
good afterwards. 


Donald Knuth, interview (1993) 


Pour ceux qui veulent se casser la téte à comprendre les pointeurs C/C++, voici 
plus d'exemples. Certains d'entre eux sont bizarres et ne servent qu'à des fins de 
démonstration: utilisez-les en production uniquement si vous savez vraiment ce que 
vous faites. 


3.23.1 Travailler avec des adresses au lieu de pointeurs 


Un pointeur est juste une adresse en mémoire. Mais pourquoi écrivons-nous char* 
string au lieu de quelque chose comme address string? La variable pointeur est 
fournie avec un type de la valeur sur laquelle le pointeur pointe. Donc le compilateur 
est capable de détecter des bugs de type de données lors de la compilation. 


Pour étre pédant, les types de données des langages de programmation ne servent 
qu'a prévenir des bugs et à l'auto-documentation. I| est possible de n'utiliser que 
deux types de données, comme int (ou int64 t) et l'octet—ce sont les seuls types 
disponible aux programmeurs en langage d'assemblage. Mais c'est une táche ex- 
trémement difficile d'écrire des programmes en assembleur pratique et sans bugs 
méchants. La plus petite typo peut conduire à un bug difficile-à-trouver. 


L'information sur le type de données est absente d'un code compilé (et c'est l'un 
des problémes majeurs pour les dé-compilateurs), et je peux le prouver. 


Ceci est ce qu'un programmeur C/C++ peut écrire: 
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#include <stdio.h> 
#include <stdint.h> 


void print_string (char *s) 


{ 
printf ("(address: Ox%llx)\n", s); 
printf ("%s\n", s); 

}; 

int main() 

{ 
char *s="Hello, world!"; 
print_string (s); 

}; 


Ceci est ce que je peux écrire: 


#include <stdio.h> 
#include <stdint.h> 


void print_string (uint64 t address) 


{ 
printf ("(address: Ox%llx)in", address); 
puts ((char*)address); 
}; 
int main() 
{ 
char *s="Hello, world!"; 
print string ((uint64 t)s); 
}; 


J'utilise uint64 t car j'ai effectué cet exemple sur Linux x64. int fonctionnerait pour 
des OS-s 32-bit. D'abord, un pointeur sur un caractère (la toute première chaîne de 
bienvenu) est casté en uint64 t, puis passé plus loin. La fonction print string() 
re-caste la valeur uint64 t en un pointeur sur un caractére. 


Ce qui est intéressant, c'est que GCC 4.8.4 produit une sortie assembleur identique 
pour les deux versions: 


gcc l.c -S -masm=intel -03 -fno-inline 


.LC0: 
.string "(address: Oxs&llx)VXn" 
print string: 


push rbx 

mov rdx, rdi 

mov rbx, rdi 

mov esi, OFFSET FLAT:.LCO 


mov edi, 1 
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xor eax, eax 
call . printf chk 
mov rdi, rbx 
pop rbx 
jmp puts 
.LC1: 
.string "Hello, world!" 
main: 
sub rsp, 8 
mov edi, OFFSET FLAT: .LC1 
call print string 
add rsp, 8 
ret 


(j'ai supprimé toutes les directives non significatives de GCC.) 


J'ai aussi essayé différents utilitaires UNIX de diff et ils ne montrent aucune diffé- 
rence. 


Continuons à abuser massivement des traditions de programmation de C/C++. On 
pourrait écrire ceci: 


#include <stdio.h> 
#include <stdint.h> 


uint8 t load byte at address (uint8 t* address) 


1 
return *address; 
//this is also possible: return address[0]; 
$; 
void print string (char *s) 
1 
char* current addressz-s; 
while (1) 
1 
char current char-load byte at address(current address); 
if (current char--0) 
break; 
printf ("%c", current char); 
current address; 
}; 
}; 
int main() 
{ 
char *s="Hello, world!"; 
print_string (s); 
}; 


Ça pourrait être récrit comme ceci: 


#include <stdio.h> 
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#include <stdint.h> 


uint8 t load byte at address (uint64 t address) 


1 
return *(uint8 t*)address; 
}; 
void print_string (uint64 t address) 
{ 
uint64 t current_address=address; 
while (1) 
{ 
char current_char=load_byte_at_address(current_address); 
if (current_char==0) 
break; 
printf ("%c", current char); 
current_address++; 
}; 
}; 
int main() 
{ 
char *s="Hello, world!"; 
print_string ((uint64_t)s); 
}; 


Les deux codes source donnent la même sortie assembleur: 


gcc 1.c -S -masm=intel -03 -fno-inline 


load byte at address: 
movzx eax, BYTE PTR [rdi] 


ret 
print string: 
.LFB15: 
push rbx 
mov rbx, rdi 
jmp .L4 
.L7: 


movsx edi, al 
add rbx, 1 
call putchar 


.L4: 
mov rdi, rbx 
call load byte at address 
test al, al 
jne .L7 
pop rbx 
ret 
.LC0: 


.string "Hello, world!" 
main: 
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sub rsp, 8 

mov edi, OFFSET FLAT: .LCO 
call print_string 

add rsp, 8 

ret 


(j'ai supprimé toutes les directives non significatives de GCC.) 


Aucune différence: les pointeurs C/C++ sont essentiellement des adresses, mais 
fournies avec une information sur le type, afin de prévenir des erreurs possible lors 
de la compilation. 


3.23.2 Passer des valeurs en tant que pointeurs; tagged unions 


Voici un exemple montrant comment passer des valeurs dans des pointeurs: 


#include <stdio.h> 
#include <stdint.h> 
uint64 t multiplyl (uint64 t a, uint64 t b) 
1 
return a*b; 
}; 
uint64 t* multiply2 (uint64 t *a, uint64 t *b) 
1 
return (uint64 t*)((uint64 t)a*(uint64 t)b); 
}; 
int main() 
{ 
printf ("%d\n", multiply1(123, 456)); 
printf ("%d\n", (uint64 t)multiply2((uint64 t*)123, (uint64 t*)456)7 
S); 
}; 


Il fonctionne sans problème et GCC 4.8.4 compile les fonctions multiply1() et multi- 
ply2() de manière identique! 


multiplyl: 
mov rax, rdi 
imul rax, rsi 
ret 

multiply2: 
mov rax, rdi 
imul rax, rsi 
ret 


Tant que vous ne déréférencez pas le pointeur (autrement dit, que vous ne lisez 
aucune donnée depuis l'adresse stockée dans le pointeur), tout se passera bien. 


778 
Un pointeur est une variable qui peut stocker n'importe quoi, comme une variable 
usuelle. 


L'instruction de multiplication signée (IMUL) est utilisée ici au lieu de la non-signée 
(MUL), lisez-en plus à ce sujet ici: 11.1 on page 1287. 


À propos, il y a une astuce trés connue pour abuser des pointeurs appelée tagged 
pointers. En gros, si tous vos pointeurs pointent sur des blocs de mémoire de taille, 
disons, 16 octets (ou qu'ils sont toujours alignés sur une limite de 16-octet), les 4 
bits les plus bas du pointeur sont toujours zéro et cet espace peut étre utilisé d'une 
certaine facon. C'est trés répandu dans les compilateurs et interpréteurs LISP. Ils 
stockent le type de cell/objet dans ces bits inutilisés, ceci peut économiser un peu 
de mémoire. Encore mieux, vous pouvez évaluer le type de cell/objet en utilisant 
seulement le pointeur, sans accés supplémentaire à la mémoire. En lire plus à ce 
sujet: [Dennis Yurichev, C/C++ programming language notes 1.3]. 


3.23.3 Abus de pointeurs dans le noyau Windows 


La section ressource d'un exécutable PE dans les OS Windows est une section conte- 
nant des images, des icónes, des chaínes, etc. Les premiéres versions de Windows 
permettaient seulement d'adresser les ressources par ID, mais Microsoft a ajouté un 
moyen de les adresser en utilisant des chaines. 


Donc, il doit étre alors possible de passer un ID ou une chaine a la fonction Elle est 
déclarée comme ceci: FindResource(). 


HRSRC WINAPI FindResource( 
.In opt HMODULE hModule, 
In. LPCTSTR lpName, 
In. LPCTSTR lpType 

); 


lpName et IpType ont un type char* ou wchar*, et lorsque quelqu'un veut encore 
passer un ID, il doit utiliser la macro MAKEINTRESOURCE, comme ceci: 


result = FindResource(..., MAKEINTRESOURCE(1234), ...); 


C'est un fait intéressant que MAKEINTRESOURCE est juste un casting d'entier vers 
un pointeur. Dans MSVC 2013, dans le fichier 
Microsoft SDKs\Windows\v7.1A\Include\Ks.h nous pouvons voir ceci: 


Hif (!defined( MAKEINTRESOURCE )) 
#define MAKEINTRESOURCE( res ) ((ULONG PTR) (USHORT) res) 
#endif 


Ça semble fou. Regardons dans l'ancien code source de Windows NT4 qui avait fuité. 
Dans private/windows/base/client/module.c nous pouvons trouver le source code de 
FindResource() : 
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HRSRC 

FindResourceA( 
HMODULE hModule, 
LPCSTR lpName, 
LPCSTR lpType 
) 


NTSTATUS Status; 
ULONG IdPath[ 3 ]; 


PVOID p; 
IdPath[ 0 ] = 0; 
IdPath[ 1] = 0; 
try { 
if ((IdPath[ O ] = BaseDllMapResourceIdA( lpType )) == -1) ( 
Status = STATUS INVALID PARAMETER; 
} 
else 
if ((IdPath[ 1 ] = BaseDllMapResourceIdA( lpName )) == -1) ( 


Status = STATUS INVALID PARAMETER; 


Continuons avec BaseDIIMapResourceldA() dans le méme fichier source: 


ULONG 
BaseDllMapResourceIdA( 
LPCSTR lpId 
) 


NTSTATUS Status; 

ULONG Id; 

UNICODE STRING UnicodeString; 
ANSI STRING AnsiString; 


PWSTR s; 
try { 
if ((ULONG)lpId & LDR RESOURCE ID NAME MASK) ( 
if (*lpId == '#') { 
Status = RtlCharToInteger( lpld+1, 10, &Id ); 
if (INT SUCCESS( Status ) || Id € LDR RESOURCE ID NAME MASK 
S) { 
if (NT_SUCCESS( Status )) { 
Status = STATUS INVALID PARAMETER; 
BaseSetLastNTError( Status ); 
Id = (ULONG)-1; 
} 
} 
else { 


RtlInitAnsiString( &AnsiString, lpId ); 
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Status = RtlAnsiStringToUnicodeString( &UnicodeString, 
SAnsiString, 
TRUE 
); 
if (!NT SUCCESS( Status )){ 
BaseSetLastNTError( Status ); 
Id = (ULONG)-1; 
} 
else { 
= UnicodeString.Buffer; 
while (*s != UNICODE NULL) { 
*s = RtlUpcaseUnicodeChar( *s ); 
Stt; 


) 


Id = (ULONG)UnicodeString.Buffer; 
} 


} 
else { 
Id = (ULONG)lpId; 
} 
} 
except (EXCEPTION EXECUTE HANDLER) { 
BaseSetLastNTError( GetExceptionCode() ); 
Id = (ULONG)-1; 
} 


return Id; 


Ipid est ANDé avec LDR RESOURCE ID NAME MASK. 
Que nous pouvons trouver dans public/sdk/inc/ntldr.h : 


define LDR RESOURCE ID NAME MASK OxFFFF0000 


Donc /pld est ANDé avec OxFFFF0000 et si des bits sont encore présents dans la par- 
tie 16-bit basse, la première partie de la fonction est exécutée (/pld est traité comme 
une adresse de chaîne). Autrement—la seconde moitié (/p/d est traitée comme une 
valeur 16-bit). 


Encore, ce code peut étre trouvé dans le fichier kernel32.dll de Windows 7: 


.text:0000000078D24510 ; 
int64 fastcall BaseDllMapResourceIdA(PCSZ SourceString) 
pus 0000000078D24510 BaseDllMapResourceIdA proc near ; CODE XREF: 


indResourceExA+34 
TU (0000000078D24510 ; 


FindResourceExA+4B 
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. text: 0000000078D24510 

.text:0000000078D24510 var 38 
.text:0000000078D24510 var 30 
.text:0000000078D24510 var 28 


.text:0000000078D24510 DestinationStrin 


.text:0000000078D24510 arg 8 
.text:0000000078D24510 


.text:0000000078D24510 ; FUNCTION CHUNK AT .text:0000000078D42FB4 SIZE 


000000D5 BYTES 
.text:0000000078D24510 


.text:0000000078D24510 
.text:0000000078D24512 
.text:0000000078D24516 
.text:0000000078D2451D 
.text:0000000078D24523 
.text:0000000078D24528 
.text:0000000078D2452A ; 


.text:0000000078D2452A 


.text:0000000078D2452A loc 78D2452A: 


BaseDllMapResourceIdA-18 
.text:0000000078D2452A 

BaseDl LMapResourceIdA+1EADO 
.text:0000000078D2452A 
.text:0000000078D2452C ; 


.text:0000000078D2452C 


.text:0000000078D2452C loc 78D2452C: 
CODE XREF: BaseDllMapResourceIdA:loc 78D2452A 


.text:0000000078D2452C 

BaseDl LMapResourceIdA+1EB74 
.text:0000000078D2452C 
.text:0000000078D2452F 
.text:0000000078D24533 
.text:0000000078D24534 
.text:0000000078D24534 ; 


.text:0000000078D24535 


.text:0000000078D24535 BaseDllMapResourceIdA endp 


. text: 0000000078D42FB4 loc 78D42FB4: 


BaseDl LMapResourceIdA+D 
. text: 0000000078D42FB4 


. text :0000000078D42FB7 
. text : 0000000078D42FB9 
. text : 0000000078D42FBC 
. text: 0000000078D42FC1 
. text: 0000000078D42FC6 
. text : 0000000078D42FCC 
. text : 0000000078D42FD0 
. text : 0000000078D42FD5 
.text:0000000078D42FD7 
.text:0000000078D42FD9 
.text:0000000078D42FE0 


- qword ptr -38h 
- qword ptr -30h 
= UNICODE STRING ptr -28h 
g= STRING ptr -18h 
= dword ptr 10h 
push rbx 
sub rsp, 50h 
cmp rcx, 10000h 
jnb loc_78D42FB4 
mov [rsp+58h+var_38], rcx 
jmp short $+2 
; CODE XREF: 
jmp short $+2 
mov rax, rcx 
add rsp, 50h 
pop rbx 
retn 
align 20h 
; CODE XREF: 
cmp byte ptr [rcx], '£' 
jnz short loc 78D43005 
inc rcx 
lea r8, [rsp+58h+arg_8] 
mov edx, OAh 
call cs: imp RtlCharToInteger 
mov ecx, [rsp+58h+arg 8] 
mov [rsp+58h+var_38], rcx 
test eax, eax 
js short loc 78D42FE6 
test rcx, OFFFFFFFFFFFF0000h 
jz loc_78D2452A 
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Si la valeur du pointeur en entrée est plus grande que 0x10000, un saut au traite- 
ment de chaínes se produit. Autrement, la valeur en entrée du /pld est renvoyée 
telle quelle. Le masque OxFFFFOOOO n'est plus utilisé ici, car ceci est du code 64-bit, 
mais encore, OxFFFFFFFFFFFFOOOO pourrait fonctionner ici. 


Le lecteur attentif pourrait demander ce qui se passe si l'adresse de la chaine en 
entrée est plus petite que 0x10000? Ce code se base sur le fait que dans Windows, 
il n'y a rien aux adresses en dessous de 0x10000, au moins en Win32 realm. 


Raymond Chen écrit à propos de ceci: 


How does MAKEINTRESOURCE work? It just stashes the integer in 
the bottom 16 bits of a pointer, leaving the upper bits zero. This relies 
on the convention that the first 64KB of address space is never mapped 
to valid memory, a convention that is enforced starting in Windows 7. 


En quelques mots, ceci est un sale hack et probablement qu'il ne devrait étre utilisé 
qu'en cas de réelle nécessité. Peut-être que la fonction FindResource() avait un type 
SHORT pour ses arguments, et puis Microsoft a ajouté un moyen de passer des 
chaines ici, mais que le code ancien devait toujours étre supporté. 


Maintenant, voici un exemple distillé: 


#include <stdio.h> 
#include <stdint.h> 


void f(char* a) 


{ 
if (((uint64 t)a)>0x10000) 
printf ("Pointer to string has been passed: %s\n", a); 
else 
printf ("16-bit value has been passed: %d\n", (uint64 t)a); 
}; 
int main() 
1 
f("Hello!"); // pass string 
f((char*)1234); // pass 16-bit value 
}; 


Ça fonctionne! 


Abus de pointeurs dans le noyau Linux 


Comme ça a déjà été pointé dans des commentaires sur Hacker News, le noyau 
Linux comporte aussi des choses comme ça. 


Par exemple, cette fonction peut renvoyer un code erreur ou un pointeur: 
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struct kernfs_node *kernfs create link(struct kernfs_node *parent, 
const char *name, 
struct kernfs node *target) 
1 
struct kernfs node *kn; 
int error; 
kn = kernfs new node(parent, name, S IFLNK|S IRWXUGO, KERNFS LINK); 
if (!kn) 
return ERR PTR( -ENOMEM) ; 
if (kernfs ns enabled(parent)) 
kn->ns = target-»ns; 
kn->symlink.target_kn = target; 
kernfs get(target); /* ref owned by symlink */ 
error = kernfs add one(kn); 
if (lerror) 
return kn; 
kernfs put(kn); 
return ERR PTR(error); 
} 


(https://github.com/torvalds/linux/blob/fceef393a538134f03b778c5d2519e670269342f/ 
fs/kernfs/symlink.czL25 ) 


ERR_PTR est une macro pour caster un entier en un pointeur: 


static inline void * | must check ERR PTR(long error) 


{ 
} 


return (void *) error; 


(https://github.com/torvalds/linux/blob/61d0b5a4b2777dcf5daef245e212b3c1fa8091ca/ 
tools/virtio/linux/err.h) 


Ce fichier d'en-téte contient aussi une macro d'aide pour distinguer un code d'erreur 
d'un pointeur: 


#define IS ERR VALUE(x) unlikely((x) >= (unsigned long) -MAX_ERRNO) 


Ceci signifie que les codes erreurs sont les “pointeurs” qui sont trés proche de -1, 
et, heureusement, il n'y a rien dans la mémoire du noyau à des adresses comme 
OxFFFFFFFFFFFFFFFF, OXFFFFFFFFFFFFFFFE, OxFFFFFFFFFFFFFFFD, etc. 


Une méthode bien plus répandue est de renvoyer NULL en cas d'erreur et de passer 
le code d'erreur par un argument supplémentaire. Les auteurs du noyau Linux ne font 
pas ca, mais quiconque veut utiliser ces fonctions doit toujours garder en mémoire 
que le pointeur renvoyé doit toujours être testé avec IS ERR VALUE avant d'être 
déréférencé. 


Par exemple: 
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fman->cam_offset = fman_muram_alloc(fman->muram, fman->cam_size); 
if (IS ERR VALUE (fman->cam_offset)) { 
dev_err(fman->dev, "*s: MURAM alloc for DMA CAM failed\n", 
. func ); 


return -ENOMEM; 


(https://github.com/torvalds/linux/blob/aa00edc1287a693eadc7bc67a3d73555d969b35d/ 
drivers/net/ethernet/freescale/fman/fman.c#L826 ) 


Abus de pointeurs dans l'espace utilisateur UNIX 


La fonction mmap() renvoie -1 en cas d'erreur (ou MAP FAILED, qui vaut -1). Cer- 
taines personnes disent que mmap() peut mapper une zone mémoire à l'adresse 
zéro dans de rares situations, donc elle ne peut pas utiliser 0 ou NULL comme code 
d'erreur. 


3.23.4 Pointeurs nuls 
"Null pointer assignment" erreur du temps de MS-DOS 


Des anciens peuvent se souvenir d'un message d'erreur bizarre du temps de MS- 
DOS: "Null pointer assignment". Qu'est-ce que ca signifie? 


Il n'est pas possible d'écrire à l'adresse mémoire zéro avec les OSs *NIX et Windows, 
mais il est possible de le faire avec MS-DOS, à cause de l'absence de protection de 
la mémoire. 


Donc, j'ai sorti mon ancien Turbo C++ 3.0 (qui füt renommer plus tard en Borland 
C++) d'avant les années 1990s et essayé de compiler ceci: 


#include <stdio.h> 


int main() 
{ 
int *ptr=NULL; 
*ptr=1234; 
printf ("Now let's read at NULL\n"); 
printf ("%d\n", *ptr); 
}; 


C'est difficile à croire, mais ça fonctionne, sans erreur jusqu'à la sortie, toutefois: 


Listing 3.124 : Ancient Turbo C 3.0 


C:\TC30\BIN\1 

Now let's read at NULL 
1234 

Null pointer assignment 


C:\TC30\BIN>_ 
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Plongeons un peu plus profondément dans le code du CRT de Borland C++ 3.1, fi- 
chier cO.asm : 


; checknull() check for null pointer zapping copyright message 


; Check for null pointers before exit 


. checknull PROC DIST 
PUBLIC . checknull 
IF LDATA EQ false 
IFNDEF . TINY . 
push si 
push di 
mov es, cs:DGROUP@G@ 
xor ax, ax 
mov si, ax 
mov cx, lgth CopyRight 
ComputeChecksum label near 
add al, es:[si] 
adc ah, 0 
inc si 
loop ComputeChecksum 
sub ax, CheckSum 
jz @@SumOK 
mov cx, lgth NullCheck 
mov dx, offset DGROUP: NullCheck 
call ErrorDisplay 
EESUMOK : pop di 
pop si 
ENDIF 
ENDIF 
DATA SEGMENT 


; Magic symbol used by the debug info to locate the data segment 
public DATASEG@ 
DATASEG@ label byte 


; The CopyRight string must NOT be moved or changed without 
; changing the null pointer check logic 


CopyRight db 4 dup(0) 
db 'Borland C++ - Copyright 1991 Borland Intl.',0 
lgth CopyRight equ $ - CopyRight 
IF LDATA EQ false 
IFNDEF . TINY _ 
CheckSum equ 00D5Ch 
NullCheck db 'Null pointer assignment', 13, 10 
lgth NullCheck equ $ - NullCheck 


ENDIF 
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ENDIF 


Le modéle de mémoire de MS-DOS était vraiment bizarre (11.7 on page 1297) et ne 
vaut probablement pas la peine de s'y plonger, à moins d'étre fan de rétro-computing 
ou de rétro-gaming. Une chose que nous devons garder à l'esprit est que le segment 
de mémoire (segment de données inclus) dans MS-DOS, est un segment de mémoire 
dans lequel du code ou des données sont stockés, mais contrairement au OSs "sé- 
rieux”, il commence à l'adresse 0. 


Et dans le CRT de Borland C++, le segment de données commence avec 4 octets 
à zéro puis la chaine de copyright “Borland C++ - Copyright 1991 Borland Intl.". 
L'intégrité des 4 octets à zéro et de la chaîne de texte est vérifiée en sortant, et s'ils 
sont corrompus, le message d'erreur est affiché. 


Mais pourquoi? Écrire à l'adresse zéro est une erreur courante en C/C++, et si vous 
faites cela sur *NIX ou Windows, votre application va planter. MS-DOS n'a pas de 
protection de la mémoire, donc le CRT doit vérifier ceci post-factum et le signaler à 
la sortie. Si vous voyez ce message, ceci signifie que votre programme à un certain 
point, a écrit à l'adresse O. 


Notre programme le fait. Et ceci est pourquoi le nombre 1234 a été lu correctement: 
car il a été écrit à la place des 4 premiers octets à zéro. La somme de contróle est 
incorrecte à la sortie (car le nombre y a été laissé), donc le message a été affiché. 


Ai-je raison? J'ai récrit le programme pour vérifier mes suppositions: 


#include <stdio.h> 


int main() 
{ 
int *ptr=NULL; 
*ptr=1234; 
printf ("Now let's read at NULL\n"); 
printf ("%d\n", *ptr); 
*ptr=0; // psst, cover our tracks! 


}; 


Ce programme s'exécute sans message d'erreur à la sortie. 


Une telle méthode pour avertir en cas d'assignation du pointeur nul est pertinente 
pour MS-DOS, peut-être qu'elle peut encore être utilisée de nos jours avec des MCUs 
à bas coût sans protection de la mémoire et/ou MMU?’. 


Pourquoi voudrait-on écrire à l’adresse 0? 


Mais pourquoi un programmeur sain d'esprit écrirait du code écrivant quelque chose 
à l'adresse 0? Ca peut être fait accidentellement: par exemple, un pointeur doit 
être initialisé au bloc de mémoire nouvellement alloué et ensuite passé à quelque 
fonction qui renvoie des données à travers un pointeur. 
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int *ptrzNULL; 
\dots nous avons oublié d'allouer la mémoire et d'initialiser ptr 


strcpy (ptr, buf); // strcpy() termine silencieusement car MS-DOS n'a pas de 
protection de la mémoire 


Encore pire: 


int *ptr=malloc(1000) ; 


\dots nous avons oublié de vérifier si la mémoire a réellement été allouée: 
$ c'est MS-DOS aprés tout et les ordinateurs ont une petite quantité ^ 
& de RAM, 

\dots et étre à court de RAM était trés courant. 

\dost si malloc() a renvoyé NULL, ptr sera aussi NULL. 


strcpy (ptr, buf); // strcpy() termine silencieusement car MS-DOS n'a pas 7 
$ de protection de la mémoire 


Écrire sciemment à l'adresse O 


Voici un exemple tiré de dmalloc**, une facon portable de générer un core dump, si 
les autres moyens ne sont pas disponibles: 


3.4 Generating a Core File on Errors 


If the ‘error-abort' debug token has been enabled, when the library 
detects any problems with the heap memory, it will immediately attempt 
to dump a core file. *Note Debug Tokens::. Core files are a complete 
copy of the program and it's state and can be used by a debugger to see 
specifically what is going on when the error occurred. *Note Using 
With a Debugger::. By default, the low, medium, and high arguments to 
the library utility enable the ‘error-abort' token. You can disable 
this feature by entering ‘dmalloc -m error-abort' (-m for minus) to 
remove the ‘error-abort' token and your program will just log errors 
and continue. You can also use the ‘error-dump' token which tries to 
dump core when it sees an error but still continue running. *Note 
Debug Tokens::. 


When a program dumps core, the system writes the program and all of 
its memory to a file on disk usually named ‘core'. If your program is 
called *foo' then your system may dump core as 'foo.core'. If you are 
not getting a ‘core' file, make sure that your program has not changed 
to a new directory meaning that it may have written the core file in a 
different location. Also insure that your program has write privileges 
over the directory that it is in otherwise it will not be able to dump 
a core file. Core dumps are often security problems since they contain 
all program memory so systems often block their being produced. You 
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will want to check your user and system's core dump size ulimit 
settings. 


The library by default uses the ‘abort' function to dump core which 
may or may not work depending on your operating system. If the 
following program does not dump core then this may be the problem. See 
"KILL PROCESS' definition in 'settings.dist'. 


main() 


1 
} 


abort(); 


If "abort' does work then you may want to try the following setting 
in 'settings.dist'. This code tries to generate a segmentation fault 
by dereferencing a "NULL' pointer. 


#define KILL PROCESS { int * int p = OL; * int p = 1; } 


NULL en C/C++ 


NULL en C/C++ est juste une macro qui est souvent définie comme ceci: 


#define NULL ((void*)0) 


( fichier libio.h ) 


void* est un type de données reflétant le fait que c'est un pointeur, mais sur une 
valeur d'un type de données inconnu (void). 


NULL est usuellement utilisé pour montrer l'absence d'un objet. Par exemple, vous 
avez une liste simplement chaînée, et chaque noeud a une valeur (ou un pointeur sur 
une valeur) et un pointeur next. Pour montrer qu'il n'y a pas de noeud suivant, O est 
stocké dans le champ next. (D'autres solutions sont pires.) Peut-étre pourriez-vous 
avoir un environnement fou où vous devriez allouer un bloc de mémoire à l'adresse 
zéro. Comment indiqueriez-vous l'absence de noeud suivant? Avec une sorte de ma- 
gic number ? Peut-étre -1? Ou peut-étre avec un bit additionnel? 


Nous trouvons ceci dans Wikipédia: 


In fact, quite contrary to the zero page's original preferential use, 
some modern operating systems such as FreeBSD, Linux and Microsoft 
Windows[2] actually make the zero page inaccessible to trap uses of 
NULL pointers. 


( https://en.wikipedia.org/wiki/Zero page) 


Pointeur nul à une fonction 


Il est possible d'appeler une fonction avec son adresse. Par exemple, je compile ceci 
avec MSVC 2010 et le lance dans Windows 7: 
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#include «windows.h» 
#include <stdio.h> 


int main() 


{ 
}; 


printf ("Ox%x\n", &MessageBoxA); 


Le résultat est 0x7578feae et ne change pas après plusieurs lancements, car user32.dll 
(où la fonction MessageBoxA se trouve) est toujours chargée à la méme adresse. Et 
aussi car ASLR?? n'est pas activé (le résultat serait différent à chaque exécution dans 
ce cas). 


Appelons MessageBoxA() par son adresse: 


#include «windows.h» 
#include <stdio.h> 


typedef int (*msgboxtype) (HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, 2 
S UINT uType); 


int main() 


1 
msgboxtype msgboxaddr=0x7578feae; 


// force to load DLL into process memory, 

// since our code doesn't use any function from user32.dll, 
// and DLL is not imported 

LoadLibrary ("user32.dll"); 


msgboxaddr(NULL, "Hello, world!", "hello", MB OK); 
}; 


Bizarre, mais ça fonctionne avec Windows 7 x86. 


Ceci est communément utilisé dans les shellcodes, car il est difficile d'y appeler des 
fonctions DLL par leur nom. Et ASLR est une contre-mesure. 


Maintenant, ce qui est vraiment bizarre, quelques programmeurs C embarqué peuvent 
être familiers avec un code comme ceci: 


int reset() 

{ 
void (*foo)(void) = 0; 
foo(); 

}; 


Qui voudrait appeler une fonction à l'adresse 0? Ceci est un moyen portable de 
sauter à l'adresse zéro. De nombreux micro-contróleurs à bas coût n'ont pas de 
protection mémoire ou de MMU et après un reset, ils commencent à exécuter le 
code à l'adresse 0, où une sorte de code d'initialisation est stocké. Donc sauter à 
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l'adresse O est un moyen de se réinitialiser. On pourrait utiliser de l'assembleur inline, 
mais si ce n'est pas possible, cette méthode portable est utilisable. 


Ca compile méme correctement avec mon GCC 4.8.4 sur Linux x64: 


reset: 
sub rsp, 8 
xor eax, eax 
call rax 
add rsp, 8 
ret 


Le fait que le pointeur de pile soit décalé n'est pas un probléme: le code d'initialisa- 
tion dans les micro-contróleurs ignorent en général les registres et l'état de la RAM 
et démarrent from scratch. 


Et bien sür, ce code planterait sur *NIX ou Windows à cause de la protection mémoire, 
et méme sans la protection mémoire, il n'y a pas de code à l'adresse O. 


GCC posséde méme des extensions non-standard, permettant de sauter à une adresse 
spécifique plutót qu'un appel à une fonction ici: http://gcc.gnu.org/onlinedocs/ 
gcc/Labels-as-Values.html. 


3.23.5 Tableaux comme argument de fonction 


On peut se demander quelle est la différence entre déclarer le type d'un argument 
de fonction en tant que tableau et en tant que pointeur? 


Il semble qu' il n'y ai pas du tout de différence: 


void write somethingl(int a[16]) 


a[5]=0; 
}; 
void write something2(int *a) 
1 
a[5]=0; 
}; 
int f() 
1 
int a[16]; 
write somethingl(a); 
write something2(a); 


GCC 4.8.4 avec optimisation : 


write somethingl: 
mov DWORD PTR [rdi+20], 0 
ret 


write something2: 
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mov DWORD PTR [rdi+20], 0 
ret 


Mais vous pouvez toujours déclarer un tableau au lieu d'un pointeur a des fins d'auto- 
documentation, si la taille du tableau est toujours fixée. Et peut-étre, des outils d'ana- 
lyse statique seraient capable de vous avertir d'un possible débordement de tampon. 
Ou est-ce possible avec des outils aujourd'hui? 


Certaines personnes, incluant Linux Torvalds, critiquent cette possibilité de C/C++ : 
https://1kml.org/1kml/2015/9/3/428. 


Le standard C99 a aussile mot-clef static [ISO/IEC 9899:TC3 (C C99 standard), (2007) 
6.7.5.3]: 


If the keyword static also appears within the [ and ] of the array 
type derivation, then for each call to the function, the value of the cor- 
responding actual argument shall provide access to the first element 
of an array with at least as many elements as specified by the size 
expression. 


Si le mot-clef static apparaît entre les [ et ] du tableau de dérivation de type, alors 
pour chaque appel à la fonction, 


3.23.6 Pointeur sur une fonction 


Un nom de fonction en C/C++ sans parenthéses, comme “printf” est un pointeur sur 
une fonction du type void (*)(). Essayons de lire le contenu de la fonction et de la 
patcher: 


#include <memory.h> 
#include <stdio.h> 


void print_something () 


{ 
printf ("we are in %s()\n", _ FUNCTION ); 
$; 
int main() 
1 


print something(); 

printf ("first 3 bytes: %x %x 9ex... Mn", 
*(unsigned char*)print something, 
*((unsigned char*)print_something+1), 
*((unsigned char*)print_something+2)); 
*(unsigned char*)print something-0xC3; // RET's opcode 
printf ("going to call patched print something():n"); 
print something(); 

printf ("it must exit at this pointin"); 


792 
Ca dit que les 3 premiers octets de la fonction sont 55 89 e5. En effet, ce sont les 
opcodes des instructions PUSH EBP etMOV EBP, ESP (se sont des opcodes x86). Mais 
alors notre programme plante, car la section text est en lecture seule. 


Nous pouvons recompiler notre exemple et rendre la section text modifiable ^ : 


gcc --static -g -Wl,--omagic -o example example.c 


Ca fonctionne! 


we are in print something() 

first 3 bytes: 55 89 e5... 

going to call patched print something(): 
it must exit at this point 


3.23.7 Pointeur sur une fonction: protection contre la copie 


Un pirate de logiciel peut trouver une fonction qui vérifie la protection et renvoie vrai 
ou faux. 


Peut-on vérifier son intégrité? Il s'avère que cela peut être fait facilement. 


D'aprés objdump, les 3 premiers octets de check protection() sont 0x55 0x89 
OxE5 (compte tenu du fait qu'il s'agit de GCC sans optimisation) : 


#include <stdlib.h> 
#include <stdio.h> 


int check protection() 


1 
// do something 
return 0; 
// or return 1; 
}; 
int main() 
1 
if (check protection()==0) 
1 
printf ("no protection installed\n"); 
exit(0); 
}; 
// ...and then, at some very important point... 
if (*(((unsigned char*)check protection)+0) != 0x55) 
{ 
printf ("1st byte has been altered\n"); 
// do something mean, add watermark, etc 
}; 
if (*(((unsigned char*)check protection)+1) != 0x89) 
1 


printf ("2nd byte has been altered\n"); 


“0http://stackoverflow.com/questions/27581279/make- text - segment -writable-elf 
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// do something mean, add watermark, etc 


}; 
if (*(((unsigned char*)check protection)+2) !- 0xe5) 
1 
printf ("3rd byte has been altered\n"); 
// do something mean, add watermark, etc 
}; 
i: 
0000054d «check protection»: 
54d: 55 push  %ebp 
54e: 89 e5 mov *sesp , sebp 
550: e8 b7 00 00 00 call 60c < x86.get pc thunk.ax> 
555: 05 7f 1a 00 00 add $0xla7f,%eax 
55a: b8 00 00 00 00 mov $0x0,%eax 
55f: 5d pop %ebp 
560: c3 ret 


Si quelqu'un patchait check protection(), votre programme peut faire quelque 
chose de méchant, peut-étre se terminer brusquement. (tracer posséde l'option 
BPMx pour ca.) 


3.23.8 Pointeur sur une fonction: un bogue courant (ou une 
typo) 


Un bogue/une typo notoire: 


int expired() 


1 
// check license key, current date/time, etc 
}; 
int main() 
{ 
if (expired) // must be expired() here 
{ 
print ("expired\n"); 
exit(0); 
} 
else 
{ 
// do something 
u 
}; 


Puisque le nom de la fonction seul est interprété comme un pointeur sur une fonction, 
ou une adresse, la déclaration if(function name) est comme if(true). 


Malheureusement, un compilateur C/C++ ne va pas générer d'avertissement. 
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3.23.9 Pointeur comme un identificateur d'objet 


Tant le langage assembleur que le C n'ont pas de fonctionnalité POO, mais il est 
possible d'écrire du code dans un style POO (il suffit de traiter une structure comme 
un objet). 


Il est intéressant que, parfois, un pointeur sur un objet (ou son adresse) soit appelé 
comme ID (dans le sens de cacher/encapsuler des données). 


Par exemple, LoadLibrary(), d'après MSDN“, renvoie une "handle to the module" “2. 
Puis, vous passez ce "handle" à une autre fonction comme GetProcAddress(). Mais 
en fait, LoadLibrary() renvoie un pointeur sur le fichier DLL mappé en mémoire. ^. 
Vous pouvez lire deux octets de l'adresse renvoyée par LoadLibrary(), et ca sera 
"MZ" (deux premiers octets de n'importe quel fichier .EXE/.DLL sur Windows). 


Il semble que Microsoft "cache" cela, afin de fournir une meilleure compatibilité as- 
cendante. Donc, le type de données de HMODULE et HINSTANCE a une autre signifi- 
cation dan Windows 16-bits. 


Probablement que ceci est la raison pour laquelle printf () posséde le modificateur 
"96p", qui est utilisé pour afficher des pointeurs (entier 32-bits sur une architecture 
32-bits et 64-bit sur une 64-bits, etc.) au format hexadécimal. L'adresse d'une struc- 
ture écrite dans des logs de debug peut aider à la retrouver dans d'autres logs. 


Voici un exemple tiré du code source de SQLite: 


struct Pager 4 


sqlite3 vfs *pVfs; /* OS functions to use for 10 */ 

u8 exclusiveMode; /* Boolean. True if locking mode==EXCLUSIVE 2 
Mc 

u8 journalMode; /* One of the PAGER JOURNALMODE * values */ 

u8 useJournal; /* Use a rollback journal on this file */ 

u8 noSync; /* Do not sync the journal if true */ 


static int pagerLockDb(Pager *pPager, int eLock) { 
int rc = SQLITE OK; 


assert( eLock==SHARED LOCK || eLock==RESERVED LOCK || eLock==» 
S EXCLUSIVE LOCK ); 
if( pPager->eLock<eLock || pPager->eLock==UNKNOWN_LOCK ){ 
rc = sqlite30sLock(pPager->fd, eLock); 
if( rc--SQLITE OK && (pPager->eLock!=UNKNOWN LOCK| | eLock==» 
S EXCLUSIVE LOCK) ){ 
pPager->eLock = (u8)eLock; 
IOTRACE(("LOCK %p %d\n", pPager, eLock)) 
} 


41 Microsoft Developer Network 
42https://msdn.microsoft.com/ru- ru/library/windows/desktop/ms684175(v=vs.85) .aspx 
43https://blogs.msdn.microsoft.com/oldnewthing/20041025 - 00/?p=37483 
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) 


return rc; 


PAGER INCR(sqlite3 pager readdb count); 

PAGER INCR(pPager-»nRead); 

IOTRACE(("PGIN %p %d\n", pPager, pgno)); 

PAGERTRACE ( ("FETCH %d page %d hash(%08x)\n", 
PAGERID(pPager), pgno, pager_pagehash(pPg) )); 


3.23.10 Oracle RDBMS et un simple ramasse miette pour C/C++ 


Il fût un temps ou j'essayais d'en apprendre plus sur Oracle RDBMS, cherchais des 
vulnérabilités, etc. C'est un énorme logiciel, et une fonction typique peut prendre 
de trés larges objets imbriqués comme arguments. Et je voulais afficher ces objets, 
sous forme d’arbres (ou de graphes). 


Je suivais aussi toutes les allocations/libérations de mémoire en interceptant les fonc- 
tions d’allocation/libération. Et lorsqu’une fonction interceptée prenait un pointeur 
sur un bloc de mémoire, je cherchais ce bloc dans une liste de blocs alloués. J’obte- 
nais sa taille + un nom court du bloc (ceci est comme "tagué" dans le noyau de l'OS 
Windows^^). 


Pour un bloc donné, je peux le balayer à la recherche de mots 32-bit (sur les OS 
32-bit) ou de mots 64-bit (sur les OS 64-bit). Chaque mot peut étre un pointeur 
sur un autre bloc. Et si c'est le cas (je trouve ceci dans un autre bloc dans mes 
enregistrements), je peux chercher récursivement. 


Et ensuite, en utilisant GraphViz, je peux générer un tel diagramme: 


^^Plus d'information sur les commentaires dans les blocs alloués: Dennis Yurichev, C/C++ programming 
language notes http://yurichev.com/C- book. html 
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emt:[qesctx: kkmqccr], 
+0004: ptr to [qcctx : k 


+0008: 0x02 0x00 0x0C 
+000C: Ox5C(\) OxD5 O 
cmt:[qcctx : kkmqccr], size:[66] 


+0004: ptr to [ctxdef.kksLoadChild] 
cmt:[qcpctx: kkmqecr], 
+0014: 0x02 0x02 0x00 0x00 
cmt:[ctxdefkksLoadChild], size:[480] ÿ +0004: 0xAB 0x92 0x6 
+001C: ptr to [qesctx: kkmqccr] 
+0000: 0x04 0x00 0x00 0x00 AENEA i +0008: ptr to [qcctx : k 
; ptr to [qCpctx: maccr 
+0004: 0x18 0x00 0x00 0x00 idi: : +0018: ptr to [qcptge: k 
+0024: ptr to [gcmemctx : kkmqccr] 
+000C: 0x18 0x00 0x00 0x00 
+0028: Ox68(h) üx7B(() OxDA 0x05 
+0040: 0x00 0x00 0x00 0x08 
+0034: ptr to [qctctx: kkmqccr] cmt:[qctctx: kkmqccr], 
+0044: 0x00 0x00 0x00 0x04 


+0038: ptr to [gcsalpath: gcsAddSqlPath] [ +0000: ptr to [qcctx : k 


+0110: 0x28(0 0xD2 0xB2 0x1A 


+0150: ptr to [Typecheck heap descriptor] 


cmt:[qememctx : kkmaccr], 


+0000: 0x24($) OxD5 0xB2 I 
+0004: ptr to [Typecheck he 


emt:[qcsqlpath: qesAddSqlF 


[ 0000: ptr to [qcsqlpath: qc: 


cmt: [kksol : kkscuf], size: [28] 


+0004: 0x11 0x00 0x00 0x00 
+0008: 0x01 0x00 0x00 0x00 


+000C: 0x08 0x00 0x00 0x00 


Images plus grosses: 1, 2. 


Ceci est assez impressionnant, compte tenu du fait que je n’ai aucune information a 
propos des types de données de toutes ces structures. Mais je peux en obtenir des 
informations. 


Maintenant le ramasse miette pour C/C++: Boehm GC 


Si vous utilisez un bloc alloué en mémoire, son adresse doit étre présente quelque 
part, comme un pointeur dans une structure ou un tableau dans un autre bloc alloué, 
ou dans une structure allouée globale, ou dans une variable locale sur la pile. S’il n'y 
a plus de pointeur sur un bloc, vous pouvez l'appeler "orphelin”, et il est une cause 
des fuites de mémoire. 


Et c'est ce qu'un GC^ fait. Il balaye tous les blocs (car il garde un oeil sur tous 
les blocs alloués) à la recherche de pointeurs. Il est important de comprendre qu'il 
n'a aucune idée du type de données de tous les champs de ces structures dans le 
blocs— ceci est important, le GC n'a aucune information sur les types. Il balayage 
juste les blocs à la recherche de mots 32-bit ou 64-bit, et regarde s'ils peuvent étre 
des pointeurs sur d'autres bloc(s). Il balaye aussi la pile. Il traite les blocs alloués 
et la pile comme des tableaux de mots, dont certains pourraient étre des pointeurs. 


^5Garbage Collector 
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Et s'il trouve un bloc alloué, qui est "orphelin", i.e., sur lequel aucun autre pointeur 
sur lui depuis un autre bloc ou la pile, ce bloc est considéré comme inutile, devant 
étre libéré. Le processus de balayage prend du temps, et c'est pourquoi les GCs sont 
critiqués. 


Ainsi, un GC comme celui de Boehm*? (pour du C pur) possède une fonction comme 

GC malloc atomic()—en l'utilisant, vous déclarez que le bloc alloué avec cette 
fonction ne contiendra jamais de pointeur vers un autre bloc. Ca peut étre une chaíne 

de texte, ou un autre type de donnée. (En effet, GC strdup() appelleGC malloc atomic().) 
Le GC ne va pas le balayer. 


3.24 Optimisations de boucle 


3.24.1 Optimisation étrange de boucle 


Ceci est une des fonctions memcpy() les plus simple jamais implémentée: 


void memcpy (unsigned char* dst, unsigned char* src, size t cnt) 


size t i; 
for (i20; i<cnt; i++) 
dst[i]ssrc[il; 
}; 


Au moins MSVC 6.0 de la fin des années 1990 jusqu'à MSVC 2013 peuvent produire 
du code vraiment étrange (ce listing est généré par MSVC 2013 x86) : 


_dst$ = 8 ; taille = 4 
_src$ = 12 ; taille = 4 
_cnt$ = 16 ; taille = 4 
_memcpy PROC 
mov edx, DWORD PTR cnt$[esp-4] 
test edx, edx 
je SHORT $LN1@f 
mov eax, DWORD PTR _dst$[esp-4] 
push esi 
mov esi, DWORD PTR src$[esp] 
sub esi, eax 
; ESI=src-dst, i.e., différence des pointeurs 
$LL8Qf : 
mov cl, BYTE PTR [esiteax] ; charger l'octet em "esi-«dst" ou en 
"src-dst«dst" au début ou juste en "src" 
lea eax, DWORD PTR [eax+1] ; dst++ 
mov BYTE PTR [eax-1], cl ; Stocker l'octet en "(dst++)--" ou 
juste en "dst" au début 
dec edx ; décrémenter le compteur jusqu'à ce 
que nous ayons fini 
jne SHORT $LL8@f 
pop esi 
$LN1@f : 
ret 0 


46https://www.hboehm. info/gc/ 
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_memcpy ENDP 


Ceci est étrange, car comment travaille les humains avec deux pointeurs? lls stockent 
les deux adresses dans deux registres ou deux emplacements mémoire. Dans ce cas, 
le compilateur MSVC stocke les deux pointeurs comme un pointeur (dst glissant dans 
EAX) et la différence entre les pointeurs src et dst (qui reste inchangée lors de l'exé- 
cution du corps de la boucle) dans ESI. (À propos, ceci est un des rare cas oü le type 
de donnée ptrdiff t peut étre utilisé.) Lorsqu'il doit charger un octet depuis src, il le 
charge en diff + dst glissant et stocke l'octet juste en dst glissant. 


Ceci est plus une astuce d'optimisation. Mais j'ai récrit cette fonction en: 


_f2 PROC 
mov edx, DWORD PTR _cnt$[esp-4] 
test edx, edx 
je SHORT $LN1@f 
mov eax, DWORD PTR dst$[esp-4] 
push esi 
mov esi, DWORD PTR src$[esp] 
; eax=dst; esi=src 
$LL8@f : 
mov cl, BYTE PTR [esi+edx] 
mov BYTE PTR [eax+edx], cl 
dec edx 
jne SHORT $LL8@f 
pop esi 
$LN1@f : 
ret 0 
_f2 ENDP 


...et ca fonctionne aussi efficacement que la version optimisée sur mon Intel Xeon 
E31220 @ 3.10GHz. Peut-étre que cette optimisation ciblait des vieux CPUs x86 des 
années 1990, puisque ce truc est utilisé au moins par l'ancien MS VC 6.0? 

Une idée? 


Hex-Rays 2.2 a du mal à reconnaître des schémas comme ca (avec de la chance, 
temporairement?) : 


void cdecl fl(char *dst, char *src, size t size) 

1 
size t counter; // edx@l 
char *sliding dst; // eax@2 
char tmp; // cl@3 


counter - size; 
if ( size ) 


sliding dst - dst; 
do 
1 
tmp = (sliding dst++)[src - dst]; // difference (src-dst) is 
calculated once, at the beginnning 
*(sliding dst - 1) - tmp; 
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--counter; 


while ( counter ); 
} 
} 


Néanmoins, cette astuce d'optimisation est souvent utilisée par MSVC (pas unique- 
ment dans des routines memcpy() DIY” maison, mais dans de nombreuses boucles 
qui utilisent deux tableaux ou plus). Donc, ça vaut le coup pour les rétro-ingénieurs 
de la garder à l'esprit. 


3.24.2 Autre optimisation de boucle 


Si vous traitez tous les éléments d'un tableau qui est situé dans la mémoire glo- 
bale, le compilateur peut l'optimiser. Par exemple, calculons la somme de tous les 
éléments du tableau de 128 int : 


#include <stdio.h> 


int a[128]; 
int sum_of_a() 
{ 
int rt=0; 
for (int i=0; i<128; i++) 
rt=rt+alil; 
return rt; 
}; 
int main() 
1 
// initialize 
for (int i20; i<128; i++) 
alil=i; 
// calculate the sum 
printf ("%d\n", sum of a()); 
}; 


GCC 5.3.1 (x86) avec optimisation peut produire ceci (IDA) : 


.text:080484B0 sum of a proc near 

.text:080484B0 mov edx, offset a 
.text:080484B5 xor eax, eax 

.text:080484B7 mov esi, esi 

.text:080484B9 lea edi, [edi+0] 
.text:080484C0 

.text:080484C0 loc_80484C0: ; CODE XREF: sum of a+1B 
.text:080484C0 add eax, [edx] 
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.text:080484C2 
.text:080484C5 
Ss 


add 
cmp 


edx, 4 
edx, offset 7 


libc start main@@GLIBC 2 0 


.text:080484CB jnz short loc 80484C0 

. text: 080484CD rep retn 

.text:080484CD sum of_a endp 

. text: 080484CD 

.bss:0804A040 public a 

.bss:0804A040 a dd 80h dup(?) ; DATA XREF: main:loc 8048338 
.bss:0804A040 ; main+19 

.bss:0804A040  bss ends 

.bss:0804A040 

extern:0804A240 ; 

extern:0804A240 

extern:0804A240 ; Segment type: Externs 

extern:0804A240 ; extern 

extern:0804A240 extrn  libc start main@@GLIBC 2 0:near 
extern:0804A240 ; DATA XREF: main+25 
extern:0804A240 ; main+5D 

extern:0804A244 extrn _ printf chk@@GLIBC 2 3 4:near 
extern:0804A248 extrn  libc start main:near 
extern:0804A248 ; CODE XREF: libc start main 
extern:0804A248 ; DATA XREF: .got.plt:off 804A00C 


Qu'est-ce que c'est que 


libc start main@@GLIBC 2 0 en 0x080484C5 ? Ceci est 


un label situé juste aprés la fin du tableau a[]. Cette fonction peut étre récrite 


comme ceci: 
int sum of a v2() 
1 
int *tmp=a; 
int rt=0; 
do 
1 
rt=rt+(*tmp); 
tmp++; 
} 
while (tmp<(a+128)); 
return rt; 
h 


La premiére version a le compteur i, et l'adresse de chaque élément du tableau 
est calculée à chaque itération. La seconde version est plus optimisée: le pointeur 
sur chaque élément du tableau est toujours prét et est déplacé de 4 octets à chaque 
itération. Comment vérifier si la boucle est terminée? II suffit de comparer le pointeur 
avec l'adresse juste aprés la fin du tableau, qui est dans notre cas l'adresse de la 


fonction 


libc start main() importée de la Glibc 2.0. Parfois ce genre de code 
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est perturbant, et ceci est une astuce d'optimisation tres répandue, c'est pourquoi 
j'ai mis cet exemple. 


Ma seconde version est trés proche de ce que fait GCC, et lorsque je la compile, le 
code est presque le méme que dans la premiére version, mais les deux premiére 
instructions sont échangées: 


.text:080484D0 public sum of a v2 
.text:080484D0 sum of a v2 proc near 
.text:080484D0 xor eax, eax 
.text:080484D2 mov edx, offset a 
.text:080484D7 mov esi, esi 
.text:080484D9 lea edi, [edi+0] 
.text:080484E0 
.text:080484E0 loc 80484E0: ; CODE XREF: sum of a v2+1B 
.text:080484E0 add eax, [edx] 
.text:080484E2 add edx, 4 
.text:080484E5 cmp edx, offset 7 

& — libc start _main@@GLIBC 2 0 
.text:080484EB jnz short loc 80484E0 
.text:080484ED rep retn 
.text:080484bED sum of a v2 endp 


Inutile de dire que cette optimisation n'est possible que si le compilateur peut calcu- 
ler l'adresse de la fin du tableau pendant la compilation. Ceci se produit si le tableau 
est global et sa taille fixée. 


Toutefois, si l'adresse du tableau est inconnue lors de la compilation, mais que la 
taille est fixée, l'adresse du label juste aprés la fin du tableau peut étre calculée. 


3.25 Plus sur les structures 


3.25.1 Parfois une structure C peut étre utilisée au lieu d'un 
tableau 


Moyenne arithmétique 


#include <stdio.h> 


int mean(int *a, int len) 


{ 
int sum=0; 
for (int i=0; i<len; i++) 
sum=sum+a[i]; 
return sum/len; 
}; 
struct five ints 
{ 
int a0; 
int al; 


int a2; 
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int a3; 
int a4; 
}; 


int main() 
{ 
struct five ints a; 
. 8302123; 
.a12456; 
.a2=789; 
.a3=10; 
a.a4=100; 
printf ("%d\n", mean(&a, 5)); 
// test: 
https: //ww.wolframalpha.com/input/?i=mean(123,456,789,10,100) 


a 
a 
a 
a 


Ceci fonctionne: la fonction mean() ne va jamais accéder aprés la fin de la structure 
five_ints, car 5 est passé, signifiant que seuls 5 entiers vont étre accédés. 


Mettre une chaine dans une structure 


#include <stdio.h> 


struct five chars 
1 
char a0; 
char al; 
char a2; 
char a3; 
char a4; 
} attribute  ((aligned (1),packed)); 


int main() 
1 
struct five chars a; 
a.a0='h'; 
a.al='i'; 
a.a2='!'; 
a.a3='\n'; 
a.a4=0; 
printf (&a); // prints "hi!" 


}; 


L'attribut ((aligned (1),packed)) doit être utilisé, car sinon, chaque champ de la struc- 
ture sera aligné sur une limite de 4 ou 8 octets. 
Résumé 


Ceci est simplement un autre exemple de la façon dont les structures et les tableaux 
sont stockés en mémoire. Peut-être qu'aucun programmeur sain ne ferait quelque 
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chose comme dans cet exemple, excepté dans le cas d'astuces spécifiques. Ou peut- 
étre dans le cas d'obfuscation de code source? 


3.25.2 Tableau non dimensionné dans une structure C 


Nous pouvons trouver certaines structures win32 avec la dernier champ défini comme 
un tableau d'un élément. 


typedef struct SYMBOL INFO { 
ULONG SizeOfStruct; 
ULONG  TypeIndex; 


ULONG MaxNameLen; 
TCHAR Name[1]; 
} SYMBOL_INFO, *PSYMBOL_INFO; 


( https://msdn.microsoft.com/en-us/library/windows/desktop/ms680686 (v= 
vs.85).aspx) 


Ceci est une astuce, signifiant que le dernier champ est un tableau de taille inconnue, 
qui doit étre calculée lors de l'allocation de la structure. 


Pourquoi: le champ Name peut-étre court, donc pourquoi le définir avec une sorte 
de constante MAX NAME qui peut étre 128, 256 et méme plus? 


Pourquoi ne pas utiliser un pointeur à la place? Alors vous devez allouer deux blocs: 
un pour la structure et pour la chaîne. Ceci peut-être plus lent et peut nécessiter un 
plus large surplus de mémoire. Donc, vous devez déréférencer le pointeur (i.e., lire 
l'adresse de la chaîne dans la structure)—ce n'est pas un probléme, mais certains 
disent que c'est un coüt supplémentaire. 


Ceci est connu comme l'astuce struct : http://c-faq.com/struct/structhack. 
html. 


Exemple: 


#include <stdio.h> 


struct st 

{ 
int a; 
int b; 
char s[]; 

}; 


void f (struct st *s) 
{ 
printf ("%d %d %s\n", s->a, S->b, S->S); 
// f() can't replace s[] with bigger string - size of allocated block 
is unknown at this point 


}; 
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int main() 
1 
#define STRING "Hello!" 

struct st *s=malloc(sizeof(struct st)+strlen(STRING)+1); // incl. 

terminating zero 

s->a=1; 

s->b=2; 

strcpy (s->s, STRING); 

f(s); 
}; 


En quelques mots, ça fonctionne car le C n'a pas de vérification des bornes d'un 
tableau. Tout tableau est traité comme ayant une taille infinie. 


Probléme: aprés l'allocation, la taille entiére du bloc alloué pour la structure est incon- 
nue (excepté pour le gestionnaire de mémoire), donc vous ne pouvez pas remplacer 
une chaine par un chaine plus large. Vous pourriez faire quelque chose comme ca si 
le champ était déclaré comme quelque chose comme s[MAX NAME]. 


Autrement dit, vous avez une structure plus un tableau (ou une chaîne) fusionnés 
ensemble dans un bloc de mémoire alloué unique. Un autre probléme est que vous 
ne pouvez évidemment pas déclarer deux tableaux comme ceci dans une structure 
unique, ou déclarer un autre champ aprés un tel tableau. 


Les cieux compilateurs nécessitent de déclarer le tableau avec au moins un élé- 
ment: s[1], les plus récents permettent de le déclarer comme un tableau de taille 
variable:s[]. Ceci est aussi appelé membre tableau flexible. 


En lire plus à ce sujet dans GCC documentation^?, MSDN documentation?*?. 


Dennis Ritchie (un des créateurs du C) a appelé ce truc «amabilité non voulue avec 
l'implémentation du C» (peut-étre pour reconnaitre la nature astucieuse de cette 
ruse). 


Aimez le ou non, utilisez le ou non: il est encore une autre démonstration de la facon 
dont les structures sont stockées dans la mémoire, c'est pourquoi j'en ai parlé. 


3.25.3 Version de structure C 


De nombreux programmeurs Windows ont vu ceci dans MSDN: 


SizeOfStruct 
The size of the structure, in bytes. This member must be set to sizeof (y 
S SYMBOL INFO). 


( https://msdn.microsoft.com/en-us/library/windows/desktop/ms680686 (v= 
vs.85).aspx) 


En effet, certaines structures comme SYMBOL_INFO commencent en effet avec ce 
champ. Pourquoi ? C'est une sorte de version de structure. 


^8https://gcc.gnu.org/onlinedocs/gcc/Zero- Length.html 
49https://msdn.microsoft.com/en-us/library/b6fae073.aspx 
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Imaginez que vous avez une fonction qui dessine un cercle. Elle prend un unique 
argument—un pointeur sur une structure avec seulement trois champs: X, Y et radius. 
Et puis, les affichages couleurs ont inondé le marché durant les années 1980. Et vous 
voulez ajouter un argument color a la fonction. Mais, disons que vous ne pouvez pas 
lui ajouter un argument (de nombreux logiciels utilisent votre API”? et ne peuvent pas 
étre recompilés). Et si un vieux logiciels utilise votre API avec un affichage couleur, 
faites que votre fonction dessine un cercle avec par défaut les couleurs noire et 
blanche. 


Un autre jour, vous ajoutez une autre possibilité: le cercle peut maintenant étre 
rempli, et le type de brosse peut étre passé. 


Voici une solution à ce probléme: 


#include <stdio.h> 


struct verl 


{ 
size t SizeOfStruct; 
int coord X; 
int coord Y; 
int radius; 
}; 
struct ver2 
1 
size t SizeOfStruct; 
int coord X; 
int coord Y; 
int radius; 
int color; 
}; 
struct ver3 
{ 
size t SizeOfStruct; 
int coord X; 
int coord Y; 
int radius; 
int color; 
int fill brush type; // 0 - do not fill circle 
}; 


void draw circle(struct ver3 *s) // latest struct version is used here 


1 
// 
we presume SizeOfStruct, coord X and coord Y fields are always present 
printf ("We are going to draw a circle at %d:%d\n", s->coord X, s-»7 
y coord Y); 


if (s->Size0fStruct>=sizeof (int)*5) 


{ 
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// this is at least ver2, 


color field is present 


printf ("We are going to set color %d\n", s->color); 


) 


if 
1 


// this is at least ver3, 


(s->Size0fStruct>=sizeof (int)*6) 


fill brush type field is present 


printf ("We are going to fill it using brush type %d\n", sv 


y -»fill brush type); 
} 
}; 


// early software version 

void call as verl() 

1 
struct verl s; 
s.Size0fStruct=sizeof(s); 
s.coord X-123; 
s.coord Y-456; 
s.radius-10; 


printf ("** %s()\n", _ FUNCTION ); 


draw circle(&s) 
$; 


// next software version 

void call as ver2() 

1 
struct ver2 s; 

.SizeOfStruct=sizeof(s); 

.coord X=123; 

.coord_Y=456; 

.radius=10; 

.color-1; 


un un un un wn 


printf ("** %s()\n", FUNCTION); 


draw circle(&s) 
$; 


// latest, the most extended version 

void call as ver3() 

1 
struct ver3 s; 

.SizeOfStruct=sizeof(s); 

.coord_X=123; 

.coord_Y=456; 

.radius-10; 

.color-1; 

sS.fill brush type-3; 


un un un un un 


printf ("** %s()\n", FUNCTION); 


draw circle(&s); 
}; 


int main() 


{ 
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call as ver1(); 
call as ver2(); 
call as ver3(); 


$; 


Autrement dit, le champ SizeOfStruct prend le róle d'un champ version of structure. 

Il pourrait être un type énuméré (1, 2, 3, etc.), mais mettre le champ SizeOfStruct à si- 
zeof(struct...) est moins sujet à l'erreur: nous écrivons simplement s.SizeOfStruct-sizeof(...) 
dans le code de l'appelant. 


En C++, ce probléme est résolu en utilisant l'hérutage (3.21.1 on page 706). Vous 
avez seulement à étendre la classe de base (appelons la Circle), puis vous aurez 
une classe ColoredCircle, et ensuite FilledColoreaCircle, et ainsi de suite. La version 
courante d'un objet (ou, plus précisemment, le type courant) sera déterminé en 
utilisant la RTTI de C++. 


Donc lorsque vous voyez SizeOfStruct quelque part dans MSDN—peut-étre que cette 
structure a été étendue au moins une fois par le passé. 


3.25.4 Fichier des meilleurs scores dans le jeu «Block out » et 
sérialisation basique 


De nombreux jeux vidéo ont un fichier des meilleurs scores, parfois appelé «Hall of 
fame». L'ancien jeu «Block out »?! (tetris 3D de 1989) ne fait pas exception, voici ce 
que nous voyons à la fin: 


Start Game 


Fig. 3.4: Table des meilleurs scores 


Maintenant, nous pouvons voir que le fichier qui a changé aprés que nous ayons 
ajouté notre nom est BLSCORE.DAT. 


51http://ww.bestoldgames.net/eng/old-games/blockout.php 
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% xxd -g 1 BLSCORE.DAT 


00000000: Oa 00 58 65 6e 69 61 2e 2e 2e 2e 2e 00 df 01 00 ..Xenia......... 
00000010: 00 30 33 2d 32 37 2d 32 30 31 38 00 50 61 75 6c .03-27-2018.Paul 
00000020: 2e 2e 2e 2e 2e 2e 00 61 01 00 00 30 33 2d 32 37 ....... a...03-27 
00000030: 2d 32 30 31 38 00 4a 6f 68 6e 2e 2e 2e 2e 2e 2e -2018.John...... 
00000040: 00 46 01 00 00 30 33 2d 32 37 2d 32 30 31 38 00 .F...03-27-2018. 
00000050: 4a 61 6d 65 73 2e 2e 2e 2e 2e 00 44 01 00 00 30 James...... D...0 
00000060: 33 2d 32 37 2d 32 30 31 38 00 43 68 61 72 6c 69 3-27-2018.Charli 
00000070: 65 2e 2e 2e 00 ea 00 00 00 30 33 2d 32 37 20 32 €........ 03-27-2 
00000080: 30 31 38 00 4d 69 6b 65 2e 2e 2e 2e 2e 2e 00 b5 018.Mike........ 
00000090: 00 00 00 30 33 2d 32 37 2d 32 30 31 38 00 50 68 ...03-27-2018.Ph 
00000040: 69 6c 2e 2e 2e 2e 2e 2e 00 ac 00 00 00 30 33 2d il........... 03- 
000000b0: 32 37 2d 32 30 31 38 00 4d 61 72 79 2e 2e 2e 2e 27-2018.Mary.... 
000000c0: 2e 2e 00 7b 00 00 00 30 33 2d 32 37 2d 32 30 31 ...f...03-27-201 
000000d0: 38 00 54 6f 6d 2e 2e 2e 2e 2e 2e 2e 00 77 00 00 8.Tom........ W.. 
000000e0: 00 30 33 2d 32 37 2d 32 30 31 38 00 42 6f 62 2e .03-27-2018.Bob. 
000000f0: 2e 2e 2e 2e 2e 2e 00 77 00 00 00 30 33 2d 32 37 ....... w...03-27 
00000100: 2d 32 30 31 38 00 -2018. 


Toutes les entrées sont clairement visibles. Le premier octet est probablement le 
nombre d’entrées. Le second est zéro, en fait, le nombre d’entrées peut-étre une 
valeurs 16-bit couvrant les deux premiers octets. 


Ensuite, apres le nom «Xenia», nous voyons les octets OxDF et 0x01. Xenia a un 
score de 479, et ceci est exactement Ox1DF en hexadécimal. Donc une valeur de 
score est probablement un entier 16-bit, ou un entier 32-bit: il y a deux octets à zéro 
de plus aprés. 


Maintenant, pensons au fait qu'à la fois les éléments des tableaux et des structures 
sont toujours placés en mémoire de maniére adjacente les uns aux autres. Cela 
nous permet d'écrire le tableau/la structure entiérement dans le fichier en utilisant 
une fonction unique write() ou fwrite(), et de le restaurer en utilisant read() ou fread(), 
aussi simplement que ca. Ceci est ce qui est appelé sérialisation de nos jours. 


Lire 


Maintenant, écrivons un petit programme en C pour lire le fichier des meilleurs 
Scores: 


#include <assert.h> 
#include <stdio.h> 
#include <stdint.h> 
#include <string.h> 


struct entry 
{ 
char name[11]; // incl. terminating zero 
uint32 t score; 
char date[11]; // incl. terminating zero 
} attribute  ((aligned (1),packed)); 
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struct highscore file 
1 
uint8 t count; 
uint8 t unknown; 
struct entry entries[10]; 
} attribute  ((aligned (1), packed)); 


struct highscore file file; 


int main(int argc, char* argv[]) 


1 
FILE* f=fopen(argv[1], "rb"); 
assert (f!=NULL); 
size t got-fread(&file, 1, sizeof(struct highscore file), f); 
assert (got--sizeof(struct highscore file)); 
fclose(f); 
for (int i20; i<file.count; i++) 
1 
printf ("name=%s score=%d date=%s\n", 
file.entries[i].name, 
file.entries[i].score, 
file.entries[i].date); 
h 
}; 


Nous avons besoin de l'attribut ((aligned (1),packed)) de GCC afin que tous les 
champs de la structure soient alignés sur une limite de 1-octet. 


Bien súr, il fonctionne: 


name=Xenia..... score=479 date=03-27-2018 
name=Paul...... score=353 date=03-27-2018 
name=John...... score=326 date=03-27-2018 
name-James..... score=324 date=03-27-2018 
name=Charlie... score=234 date=03-27-2018 
name=Mike...... score=181 date=03-27-2018 
name=Phil...... score=172 date=03-27-2018 
name=Mary...... score=123 date=03-27-2018 
name=T0M....... score=119 date=03-27-2018 
name-Bob....... score=119 date=03-27-2018 


(Inutile de dire que chaque nom est complété avec des points, a la fois a l'écran et 
dans le fichier, peut-étre pour des raisons esthétique.) 
Écrire 


Vérifions si nous avons raison à propos de la largeur de la variable du score. Est-ce 
réellement sur 32 bits? 


int main(int argc, char* argv[]) 

1 
FILE* f=fopen(argv[1], "rb"); 
assert (f!zNULL); 
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size t got-fread(&file, 1, sizeof(struct highscore file), f); 
assert (got--sizeof(struct highscore file)); 
fclose(f); 


strcpy (file.entries[1].name, "Mallory..."); 
file.entries[1].score=12345678; 
strcpy (file.entries[1].date, "08-12-2016"); 


f=fopen(argv[1], "wb"); 

assert (f!zNULL); 

got=fwrite(&file, 1, sizeof(struct highscore file), f); 
assert (got--sizeof(struct highscore file)); 

fclose(f); 


$; 


Lancons Blockout: 


Fig. 3.5: Table des meilleurs scores 


Les deux premiers chiffres (1 et 2) ne sont pas affichés: 12345678 devient 345678. 
Peut-étre est-ce un probléme de formatage... mais le nombre est presque correct. 
Maintenant, je le change en 999999 et relance le jeu: 
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Fig. 3.6: Table des meilleurs scores 


Maintenant, c'est correct. Oui, la valeur du score est un entier 32-bit. 


Est-ce de la sérialisation? 


...presque. Ce genre de sérialisation est trés populaire dans les logiciels scientifiques 
et d'ingénierie, où l'efficacité et la rapidité sont bien plus importantes que de conver- 
tir de et vers XML?? ou JSON??. 


Une chose importante est que vous ne pouvez évidemment pas sérialiser des poin- 
teurs, car à chaque fois que vous chargez le programme en mémoire, toutes les 
structures peuvent étre allouées à des endroits différents. 


Mais, si vous travaillez sur des sortes de MCU à bas coût avec un simple OS dessus 
et que vous avez vos structures toujours allouées à la méme place en mémoire, 
peut-étre pouvez-vous sauver et restaurer de la sorte. 


Bruit aléatoire 


Lorsque je préparais cet exemple, j'ai dú lancer «Block out» de nombreuses fois 
et jouer un peu avec pour remplir la table des meilleurs scores avec des noms au 
hasard. 


Et lorsqu'il y avait seulement 3 entrées dans le fichier, j'ai vu ceci: 


00000000: 03 00 54 6f 6d 61 73 2e 2e 2e 2e 2e 00 da 2a 00 ..Tomas....... +; 
00000010: 00 30 38 2d 31 32 2d 32 30 31 36 00 43 68 61 72 .08-12-2016.Char 
00000020: 6c 69 65 2e 2e 2e 00 8b le 00 00 30 38 2d 31 32 lie........ 08-12 
00000030: 2d 32 30 31 36 00 4a 6f 68 Ge 2e 2e 2e 2e 2e 2e -2016.John...... 
00000040: 00 80 00 00 00 30 38 2d 31 32 2d 32 30 31 36 00 ..... 08-12-2016. 
00000050: 00 00 57 c8 a2 01 06 01 ba f9 47 c7 05 00 f8 4f ..W....... G....0 
00000060: 06 01 06 01 a6 32 00 00 00 00 00 00 00 00 00 00 ..... Daga 
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00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
00000020: 00 00 00 00 00 00 00 00 00 00 93 c6 a2 01 46 72 .............. Fr 
000000b0: 8c f9 f6 c5 05 00 f8 4f 00 02 06 01 a6 32 06 O1 ....... Ü. ur. 255 
000000c0: 00 00 98 f9 f2 cO 05 00 f8 4f 00 02 a6 32 a2 f9 ......... 0... 
000000d0: 80 cl a6 32 a6 32 f4 4f aa f9 39 cl a6 32 06 01 ...2. 
000000e0: b4 f9 2b c5 ab 32 el 4f c7 c8 a2 01 82 72 c6 f9 ..+.. ; 
000000f0: 30 cO 05 00 00 00 00 00 00 00 a6 32 d4 f9 76 2d 0.......... 2..V- 
00000100: a6 32 00 00 00 00 ii 


Le premier octet a la valeur 3, signifiant qu'il y a 3 entrées. Et ces 3 entrées sont 
présentes. Mais nous avons des valeurs aléatoires dans la seconde moitié du fichier. 


Le bruit provient probablement de données non initialisées. Peut-étre que «Block 
out » alloue de la mémoire pour 10 entrées quelque part dans le tas, oü, manifeste- 
ment, des valeurs pseudo-aléatoires (laissées par quelque chose d'autre) sont pré- 
sentes. Ensuite il a rempli les premier/second octet, 3 entrées, et puis n'a jamais 
touché aux 7 autres entrées, donc elles ont été écrites dans le fichier telles quelles. 


Lorsque «Block out» charge le fichier des meilleurs scores la fois suivante, il lit le 
nombre d'entrée dans les 2 premiers octets (3) et puis ignore ce qui vient aprés 
elles. 


Ceci est un probléme courant. Pas un probléme au sens strict: ce n'est pas un bogue, 
mais de l'information peut fuiter à l'extérieur. 


Les versions de Microsoft Word des années 1990 laissaient souvent des morceaux 
de texte précédemment édité dans les fichiers *.doc*. C'était alors une sorte de dis- 
traction d'obtenir un fichier .doc de quelqu'un d'autre, de l'ouvrir dans un éditeur 


LEZ Zo ye 


teur. 


Le probléme peut étre beaucoup plus sérieux: le bogue Heartbleed dans OpenSSL. 


Devoir 


«Block out» a plusieurs types de pièces (plat/basique/étendu), la taille peut être 
configurée, etc. Et il semble que pour chaque configuration, «Block out » ason propre 
tableau des meilleurs scores. J'ai remarqué que de l'information est probablement 
stockée dans le fichier BLSCORE.IDX. Ceci peut étre un travail pour les fans de «Block 
out »—de comprendre aussi sa structure. Les fichiers de «Block out » sont ici: http: 
//beginners.re/examples/blockout.zip (incluant le fichier binaire des meilleurs 
scores que j'ai utilisé dans cet exemple). Vous pouvez utiliser DosBox pour le lancer. 


3.26 memmove() et memcpy() 


La différence entre ces deux fonctions standards est que memcpy() copie aveuglé- 
ment un bloc à un autre endroit, alors que memmove() gére correctement les blocs 
qui se recouvrent. Par exemple, si vous voulez déplacer une chaîne de deux octets 
en arriére: 


813 


"|. .[hleltltio]...^ -> “|h]e]l|llo|...* 


memcpy() qui copie des mots de 32-bit ou de 64-bit à la fois, ou méme SIMD, va 
manifestement échouer ici, une routine de copie par octet doit étre utilisée à la 
place. 


Maintenant un exemple encore plus avancé, insérer deux octets au début d'une 
chaine: 


"Ihlelt[t]o]...^ ->°|.|.[hleltitlo|... 


Maintenant, méme une copie octet par octet va échouer, car vous devez copier en 
partant de la fin. 


C'est un cas rare oü le flag x86 DF doit étre mis avant l'instruction REP MOVSB : DF 
défini la direction, et maintenant, nous devons déplacer en arriére. 


La routine memmove() typique fonctionne comme ceci: 1) si la source est avant la 
destination, copier en avant; 2) sila source est aprés la destination, copier en arriére. 


Ceci est la fonction memmove() de uClibc: 


void *memmove(void *dest, const void *src, size t n) 


1 
int eax, ecx, esi, edi; 
. asm volatile ( 
" movl %%eax, %%edi\n" 
" cmpl %%esi, %%eax\n" 
il je 2f\n" /* (optional) src == dest -> NOP */ 
D jb 1f\n" /* src > dest -> simple copy */ 
" leal -1(%%esi,%%ecx), %%esi\n" 
7 leal -1(%%eax,%%ecx), %%edi\n" 
5 std\n" 
"1: rep; movsb\n" 
e cld\n" 
"2:\n" 
"-&c" (ecx), "=&S" (esi), "=8a" (eax), "=8D" (edi) 
"0" (n), "1" (src), "2" (dest) 
"memory" 
T 
return (void*)eax; 
} 


Dans le premier cas, REP MOVSB est appelée avec le flag DF à zéro. Dans le second, 
DF est mis, puis remis à zéro. 


Un algorithme plus complexe contient la logique suivante: 


«Si la différence entre la source et la destination est plus grande que la largeur d'un 
mot, copier en utilisant des mots plutôt que des octets, et utiliser une copie octet 
par octet pour copier les parties non alignées. » 


Voici comment ça se passe dans la partie C non optimisée de la Glibc 2.24. 
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Compte tenu de cela, memmove() peut étre plus lente que memcpy(). Mais certains, 
Linus Torvalds inclus, argumentent?^^ que memcpy() devrait être un alias (ou syno- 
nyme) de memmove(), et cette derniére fonction devrait juste tester au début, si les 
buffers se recouvrent ou non, et ensuite se comporter comme memcpy() ou mem- 
move(). De nos jours, le test de recouvrement de buffers est peu coûteux, après 
tout. 


3.26.1 Stratageme anti-debugging 


J'ai entendu parler de stratagéme anti-debugging oü tout ce que vous devez faire 
pour crasher le processus est de mettre DF : le prochain appel à memcpy() va 
conduire au crash, car il copiera en arriére. Mais je ne peux pas tester ceci: il semble 
que toutes les routines de copie de mémoire mettent DF à 1/0 comme elles le veulent. 
D'un autre cóté, memmove() de uClibc que j'ai déjà cité ici, ne remet pas explicite- 
ment DF à zéro (assume-t-elle que DF est toujours à zéro?), donc ca peut vraiment 
planter. 


3.27 setjmp/longjmp 


Il s'agit d'un mécanisme en C qui est trés similaire au mecanisme throw/catch en 
C++ ou d'autres LPs de haut niveau. Voici un exemple tiré de la zlib: 


/* return if bits() or decode() tries to read past available input */ 


if (setjmp(s.env) != 0) /* if came back here via longjmp(), / 
Ke * / 
err = 2; /* then skip decomp(), return 2 
L error */ 
else 


err - decomp(&s); /* decompress */ 


/* load at least need bits into val */ 
val = s->bitbuf; 
while (s->bitcnt < need) { 


if (s->left == 0) ( 

s->left = s->infun(s->inhow, &(s->in)); 

if (s->left == 0) longjmp(s->env, 1); /* out of input */ 
if (s->left == 0) ( 

s->left = s->infun(s->inhow, &(s->in)); 

if (s->left == 0) longjmp(s->env, 1); /* out of input */ 


( zlib/contrib/blast/blast.c ) 
*Ahttps://bugzilla.redhat.com/show bug.cgi?id-6384774c132 
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L'appel à setjmp() sauve les valeurs courantes de PC, SP et autres registres dans 
une structure env, puis renvoie O. 


En cas d'erreur, Longjmp() vous téléporte au point juste aprés l'appel à setjmp(), 
comme si l'appel à setjmp() avait renvoyé une valeur non nulle (qui avait été passée 
à longjmp()). Ceci nous rappel l'appel systéme fork() sous UNIX. 


Maintenant, regardons un exemple épuré: 


#include <stdio.h> 
#include <setjmp.h> 


jmp_buf env; 


void f2() 

{ 
printf ("%s() begin\n", _ FUNCTION ); 
// something odd happened here 
longjmp (env, 1234); 


printf ("%s() end\n", FUNCTION); 
$; 
void f1() 
1 
printf ("%s() begin\n", _ FUNCTION _); 
f20); 
printf ("%s() end\n", _ FUNCTION ); 
$; 
int main() 
t 
int errzsetjmp(env); 
if (err==0) 
1 
f1(); 
} 
else 
{ 
printf ("Error %d\n", err); 
}; 
}; 


Si nous le lançons, nous voyons: 


f1() begin 
f2() begin 
Error 1234 


La structure jmp_buf est généralement non-documentée, pour préserver la compa- 
tibilité ascendante. 


Regardons comment setjmp() est implémenté dans MSVC 2013 x64: 
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; RCX = address of jmp buf 


mov [rcx], rax 

mov [rcx+8], rbx 

mov [rcx+18h], rbp 

mov [rcx+20h], rsi 

mov [rcx+28h], rdi 

mov [rcx+30h], r12 

mov [rcx+38h], r13 

mov [rcx+40h], r14 

mov [rcx+48h], r15 

lea r8, [rsp+arg 0] 

mov [rcx+10h], r8 

mov r8, [rsp+0] ; get saved RA from stack 
mov [rcx+50h], r8 ; Save it 


stmxcsr dword ptr [rcx+58h] 

fnstcw word ptr [rcx+5Ch] 

movdqa xmmword ptr [rcx+60h], xmm6 
movdga xmmword ptr [rcx+70h], xmm7 
movdqa xmmword ptr [rcx+80h], xmm8 
movdqa xmmword ptr [rcx+90h], xmm9 
movdqa xmmword ptr [rcx+0A0h], xmm10 
movdqa xmmword ptr [rcx+0B0h], xmm11 
movdqa xmmword ptr [rcx+0C0h], xmm12 
movdqa xmmword ptr [rcx+0D0h], xmm13 
movdqa xmmword ptr [rcx+0E0h], xmml4 
movdqa xmmword ptr [rcx+0FOh], xmm15 
retn 


Cela remplit juste la structure jmp buf avec la valeur courante de presque tous les 
registres. Aussi, la valeur courante de RA est prise de la pile et sauvée dans jmp buf: 
elle sera utilisée comme nouvelle valeur de PC dans le futur. 


Maintenant longjmp() : 


; RCX = address of jmp buf 


mov rax, rdx 

mov rbx, [rcx+8] 

mov rsi, [rcx+20h] 

mov rdi, [rcx+28h] 

mov r12, [rcx+30h] 

mov r13, [rcx+38h] 

mov r14, [rcx+40h] 

mov r15, [rcx+48h] 
ldmxcsr dword ptr [rcx+58h] 
fnclex 


fldcw word ptr [rcx+5Ch] 
movdqa xmm6, xmmword ptr [rcx+60h] 
movdqa xmm7, xmmword ptr [rcx+70h] 
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movdqa xmm8, xmmword ptr [rcx+80h] 

movdqa xmm9, xmmword ptr [rcx+90h] 

movdqa xmm10, xmmword ptr [rcx+0A0h] 
movdga xmmll, xmmword ptr [rcx+0B0h] 
movdqa xmm12, xmmword ptr [rcx+0C0h] 
movdqa xmm13, xmmword ptr [rcx+0D0h] 
movdqa xmml4, xmmword ptr [rcx+0E0h] 
movdqa xmm15, xmmword ptr [rcx+0FOh] 


mov rdx, [rcx+50h] ; get PC (RIP) 

mov rbp, [rcx+18h] 

mov rsp, [rcx+10h] 

jmp rdx ; jump to saved PC 


Cela restaure (presque) tous les registres, prend RA dans la structure et y saute. 
Ceci fonctionne en effet comme si setimp() retournait a l'appelant. Aussi, RAX est 
mis pour étre égal au second argument de longjmp(). Ceci fonctionne comme si 
setimp() renvoyait une valeur non-zéro en premiere place. 


Comme effet de bord de la restauration de SP, toutes les valeurs dans la pile qui ont 
été définies et utilisées entre les appels a setimp() et longjmp() sont laissées tomber. 


Elles ne seront plus utilisées du tout. Ainsi, longjmp() saute usuellement en arriére 
55 


Ceci implique que, contrairement au mécanisme throw/catch en C++, aucune mé- 
moire ne sera libérée, aucun destructeur ne sera appelé, etc. Ainsi, cette technique 
peut parfois étre dangereuse. Néanmoins, elle est assez populaire. C'est toujours 
utilisé dans Oracle RDBMS. 


Cela a aussi un effet de bord inattendu: si un buffer a été dépassé dans une des 
fonctions (peut-étre a cause d’une attaque distante), et qu’une fonction veut signaler 
une erreur, et ca appelle longimp(), la partie de la pile récrite ne sera pas utilisée. 


À titre d'exercice, vous pouvez essayer de comprendre pourquoi tous les registres 
ne sont pas sauvegardés. Pourquoi XMMO-XMM5 et d'autres registres sont évités? 


3.28 Autres hacks bizarres de la pile 


3.28.1 Accéder aux arguments/variables locales de l'appelant 


Des bases de C/C++, nous savons qu'il est impossible à une fonction d'accéder aux 
arguments de la fonction appelante ou à ses variables locales. 


Néanmoins, c'est possible en utilisant des astuces tordues. Par exemple: 


#include <stdio.h> 


void f(char *text) 


55Toutefois, il y a des gens qui l'utilisent pour des choses bien plus compliquées, imitation des corou- 
tines, etc.: https://www.embeddedrelated.com/showarticle/455.php, http://fanf.livejournal. 
com/105413.html 
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1 
// print stack 
int *tmp=&text; 
for (int i=0; i<20; i++) 
1 
printf ("Ox%x\n", *tmp); 
tmp++; 
}; 
}; 
void draw text(int X, int Y, char* text) 
1 
f(text); 
printf ("We are going to draw [%s] at %d:%d\n", text, X, Y); 
}; 
int main() 
{ 
printf ("address of main()=0x%x1n", &main); 
printf ("address of draw text()=0x%x\n", &draw text); 
draw text(100, 200, "Hello!"); 
}; 


Sur Ubuntu 32-bit avec GCC 5.4.0, j'obtiens ceci: 


address of main()=0x80484f8 

address of draw_text()=0x80484cb 

0x8048645 first argument to f() 
0x8048628 

Oxbfd8ab98 

0xb7634590 

0xb779eddc 

0xb77e4918 

Oxbfd8aba8 

0x8048547 return address into the middle of main() 
0x64 first argument to draw text() 
0xc8 second argument to draw text() 
0x8048645 third argument to draw text() 
0x8048581 

0xb779d3dc 

Oxbfd8abcO 

0x0 

0xb7603637 

0xb779d000 

0xb779d000 

0x0 

0xb7603637 


(Les commentaires sont miens.) 


Puisque f() commence á énumérer les éléments de la pile a son premier argument, 
le premier élément de la pile est en effet un pointeur sur la chaíne «Hello! ». Nous 
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voyons que son adresse est aussi utilisée comme troisiéme argument de la fonction 
draw text(). 


Dans f() nous pouvons lire tous les arguments des fonctions et les variables locales si 
nous connaissons exactement l'agencement de la pile, mais ca change toujours d'un 
compilateur à l'autre. Des niveaux d'optimisation différents modifient grandement 
la structure de la pile. 


Mais, si nous pouvons d'une maniere ou d'une autre détecter l'information dont nous 
avons besoin, nous pouvons l'utiliser et méme la modifier. A titre d'exemple, j'ai 
retravaillé la fonction f() : 


void f(char *text) 


1 
// find 100, 200 values pair and modify the second on 
tmp=6text ; 
for (int i20; i<20; i++) 
1 
if (*tmp==100 && *(tmp+1)==200) 
1 
printf ("found\n"); 
* (tmp+1)=210; // change 200 to 210 
break; 
}; 
tmp++; 
h 
}; 


Hé mais, ça fonctionne: 


found 
We are going to draw [Hello!] at 100:210 


Résumé 


C'est vraiment un sale hack, dont le but est de montrer l'intérieur de la pile. Je n'ai 
jamais vu ni entendu dire que quelqu'un ai utilisé ceci dans du code réel. Mais encore, 
ceci est un bon exemple. 


Exercice 


L'exemple a été compilé sans optimisation sur Ubuntu 32-bit avec GCC 5.4.0 et il 
fonctionne. Mais lorsque j'active l'optimisation maximum -03, ca plante. Essayez de 
trouver pourquoi. 


Utilisez votre compilateur et OS favori, essayez différents niveaux d'optimisation, 
trouvez si ça fonctionne et si ça ne fonctionne pas, trouvez pourquoi. 
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3.28.2 Renvoyer une chaine 


Ceci est un bug classique tiré de Brian W. Kernighan, Rob Pike, Practice of Program- 
ming, (1999) : 


#include <stdio.h> 
char* amsg(int n, char* s) 
{ 
char buf[100]; 
sprintf (buf, "error %d: %s\n", n, S) ; 
return buf; 
}; 
int main() 
1 
printf ("%s\n", amsg (1234, "something wrong!")); 
}; 


Il va planter. Tout d'abord essayons de comprendre pourquoi. 


Ceci est l'état de la pile avant le retour de amsg() : 


(lower addresses) 


[amsg(): 100 bytes] 

[RA] «- current SP 
[two amsg arguments] 

[something else] 

[main() local variables] 


(upper addresses) 


Ensuite amsg() rend le contróle du flux à main(), jusqu'ici, tout va bien. Mais printf() 
est appelée depuis main(), qui, en fait, utilise la pile pour ses propres besoin, zap- 
pant le buffer de 100-octet. Au mieux, du contenu indéterminé sera affiché. 


Difficile à croire, mais je sais comment résoudre ce probléme: 


#include <stdio.h> 

char* amsg(int n, char* s) 

{ 
char buf[100]; 


sprintf (buf, "error %d: %s\n", n, S) ; 


return buf; 
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}; 
char* interim (int n, char* s) 
{ 
char large buf[8000]; 
// make use of local array. 
// it will be optimized away otherwise, as useless. 
large buf[0]=0; 
return amsg (n, s); 
}; 
int main() 
{ 
printf ("%s\n", interim (1234, "something wrong!")); 
}; 


Cela va fonctionner si il est compilé avec MSVC 2013 sans optimisation et avec 
l'option /GS- option. MSVC avertira: “warning C4172: returning address of local 
variable or temporary", mais le code s'exécutera et le message sera affiché. Regar- 
dons l'état de la pile au moment oü amsg() renvoie le contróle à interim() : 


(lower addresses) 


[amsg(): 100 bytes] 

[RA] «- current SP 
[two amsg() arguments] 

[interim() stuff, incl. 8000 bytes] 

[something else] 

[nain() local variables] 


(upper addresses) 


Maintenant, l'état de la pile au moment ou interim() rend le contrôle à main() : 


(lower addresses) 


[amsg(): 100 bytes] 

[RA] 

[two amsg() arguments] 

[interim() stuff, incl. 8000 bytes] 

[something else] «- current SP 
[main() local variables] 


(upper addresses) 


56Supprimer la vérification de sécurité du buffer 
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Donc lorsque main() appelle printf (), elle utilise l'espace de pile ou le buffer d'in- 
terim() était alloué, et ne zappe pas les 100 octets contenant le message d'erreur, 
car 8000 octets (ou peut-étre bien moins) sont suffisants pour tout ce que printf() 
et les autres fonctions font! 


Ca pourrait aussi fonctionner si il y a plusieurs fonctions entre, comme: main() ^ 
f1() > f2() > f3() ... > amsg(), et alors le résultat de amsg() est utilisé dans main(). 
La distance entre SP dans main() et l'adresse de buf [] doit être assez grande. 


C'est pourquoi les bugs de ce genre sont dangereux: parfois votre code fonctionne 
(et le bug ne se produit pas), parfois non. Ces genres de bug sont par humour 
appelés heisenbugs ou schródinbugs. 


3.29 OpenMP 


OpenMP est l'un des moyens les plus simple de paralléliser des algorithmes simples. 


À titre d'exemple, essayons de construire un programme pour calculer une nonce 
cryptographique. 


Dans mon exemple simpliste, le nonce est un nombre ajouté au texte non chiffré 
afin de produire un hash avec quelques caractéristiques spécifiques. 


Par exemple, à certaines étapes, le protocole Bitcoin nécessite de trouver de tels 
nonce dont le hash résultant contient un nombre spécifique de zéros consécutifs. 
Ceci est aussi appelé «preuve de travail» °’ (i.e., le système prouve qu'il a fait des 
calculs intensifs et y a passé du temps). 


Mon exemple n'est en aucun cas lié au Bitcoin, il va essayer d'ajouter des nombres 
à la chaîne afin de trouver un nombre tel que le hash de «hello, world! «number» » 
avec l'algorithme SHA512, contiendra au moins 3 octets à zéro. 


Limitons notre recherche brute-force dans l'intervalle 0..INT32_MAX-1 (i.e., Ox7FFFFFFE 
ou 2147483646). 


L'algorithme est assez direct: 


#include <stdio.h> 
#include <string.h> 
#include <stdlib.h> 
#include <time.h> 

#include "sha512.h" 


int found=0; 
int32 t checked=0; 


int32 t* min; 


int32 t* max; 


time t start; 


#ifdef — GNUC - 


?7Wikipédia 
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define min(X,Y) (00 < (Y) ? (X) : (Y)) 
define max(X,Y) ((X) > (Y) ? (X) : (Y)) 
#endif 
void check_nonce (int32 t nonce) 
{ 
uint8 t buf[32]; 
struct sha512 ctx ctx; 
uint8 t res[64]; 
// update statistics 
int t=omp get thread num(); 
if ( min[t]==-1) 
. min[t]=nonce; 
if (__max[t]==-1) 
. max[t]=nonce; 
. min[t]=min(_ min[t], nonce); 
. max[t]=max(__max[t], nonce); 
// idle if valid nonce found 
if (found) 
return; 
memset (buf, 0, sizeof(buf)); 
sprintf (buf, "hello, world! %d", nonce); 
sha512 init ctx (&ctx); 
sha512 process bytes (buf, strlen(buf), &ctx); 
sha512 finish ctx (&ctx, &res); 
if (res[0]==0 && res[1]==0 && res[2]==0) 
1 
printf ("found (thread %d): [%s]. seconds spent=%d\n", t, 
S buf, time(NULL) -start); 
found=1; 
h 
#pragma omp atomic 
checked++; 
#pragma omp critical 
if ((checked % 100000)==0) 
printf ("checked=%d\n", checked); 
}; 
int main() 
1 


int32 t i; 
int threads=omp get max threads(); 
printf ("threads=%d\n", threads); 


__min=(int32 t*)malloc(threads*sizeof(int32 t)); 
__max=(int32 t*)malloc(threads*sizeof(int32 t)); 


r4 
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for (i=0; i<threads; i++) 
. min[il=_max[il=-1; 


start-time(NULL); 


#pragma omp parallel for 
for (i20; i«INT32 MAX; i++) 
check nonce (i); 


for (i20; i«threads; i++) 
printf (" min[%d]=0x%08x — max[%d]=0x%08x\n", i, _ min[i],2 
& i,  max[i]); 


free( min); free( max); 


}; 


La fonction check nonce() ajoute simplement un nombre à la chaîne, hashe le ré- 
sultat avec l'algorithme SHA12 et teste si il y a 3 octets à zéro dans le résultat. 


Une partie très importante du code est: 


#pragma omp parallel for 
for (i=0; i«INT32 MAX; i++) 
check nonce (i); 


Oui, c'est simple, sans le #pragma nous appelons check nonce() pour chaque nombre 
de 0 à INT32 MAX (0x7fffffff ou 2147483647). Avec le #pragma, le compilateur 
ajoute du code particulier qui découpe l'intervalle de la boucle en des plus petits, 
afin de les lancer sur tous les cœurs de CPU disponible>®. 


L'exemple peut être compilé°? dans MSVC 2012: 


cl openmp example.c sha512.0bj /openmp /01 /Zi /Faopenmp example.asm 


Ou dans GCC: 


gcc -fopenmp 2.c sha512.c -S -masm=intel 


3.29.1 MSVC 
Maintenant voici comment MSVC 2012 génére la boucle principale: 


Listing 3.125 : MSVC 2012 


push OFFSET main$omp$1 


push 0 
push 1 
call . vcomp fork 


add esp, 16 


58N.B.: Ceci est intentionnellement l'exemple le plus simple possible, mais en pratique, l'utilisation de 
OpenMP peut étre plus difficile et plus complexe. 

59Les fichiers sha512.(c|h) et u64.h peuvent être pris de la bibliothèque OpenSSL: http: //www.openssl. 
org/source/ 
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Toutes les fonctions préfixées par vcomp sont relatives a OpenMP et sont stockées 
dans le fichier vcomp*.dll. Donc, ici un groupe de threads est démarré. 


Regardons main$omp$1: 


Listing 3.126 : MSVC 2012 


$T1 - -8 ; size = 4 
$T2 = -4 ; size = 4 
 main$omp$1 PROC 
push ebp 
mov ebp, esp 
push ecx 
push ecx 
push esi 
lea eax, DWORD PTR $T2[ebp] 
push eax 
lea eax, DWORD PTR $T1[ebp] 
push eax 
push T 
push 1 
push 2147483646 ; 7ffffffeH 
push 0 
call vcomp for static simple init 
mov esi, DWORD PTR $T1[ebp] 
add esp, 24 
jmp SHORT $LN6@main$omp$1 
$LL2@main$omp$1: 
push esi 
call _check_nonce 
pop ecx 
inc esi 
$LN6@main$omp$1: 
cmp esi, DWORD PTR $T2[ebp] 
jle SHORT $LL2@main$omp$1 
call vcomp for static end 
pop esi 
leave 
ret 0 


 main$omp$1 ENDP 


Cette fonction va étre démarrée n fois en paralléle, oü » est le nombre de coeurs du 
CPU. 

vcomp for static simple init() calcul l'intervalle pour la construction for() du 
thread courant, dépendant du numéro du thread courant. 


Les valeurs de début et de fin sont stockées dans les variables locales $T1 et $T2. 
Vous pouvez également remarquer l'argument 7ffffffeh (ou 2147483646) comme 
argument de la fonction 

vcomp for static simple init()—ceci est le nombre d'itérations de la boucle 
complète, 

qui doit éventuellement être divisée. 


Puis nous voyons une nouvelle boucle avec un appel à la fonction check nonce(), 
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qui fait tout le travail. 


Ajoutons du code au début de la fonction check_nonce() pour collecter des statis- 
tiques sur les arguments avec lesquels la fonction a été appelée. 


Voici ce que nous pouvons voir lorsque nous le lancons: 


threads=4 


checked=2800000 

checked=3000000 

checked=3200000 

checked=3300000 

found (thread 3): [hello, world! 1611446522]. seconds spent=3 
. min[0]-0x00000000 _max[0]=0x1fffffff 

. min[1]=0x20000000 _ max[1]s0Ox3fffffff 

. min[2]=0x40000000 _ max[2]-0x5fffffff 

. min[3]-0x60000000 _ max[3]-0x7ffffffe 


Oui, le résultat est correct, les 3 premiers octets sont des zéros: 


C:\...\sha512sum test 
000000f4a8fac5a4ed38794da4c1e39f154279ad5d9bb3c5465cdf57adaf 60403 
df6e3fe6019f5764fc9975e505a7395fed780fee50eb38dd4c0279cb114672e2 *test 


Le temps de traitement est x 2..3 secondes sur un Intel Xeon E3-1220 3.10 GHz 4- 
core. Dans le gestionnaire de táches nous voyons 5 threads: 1 thread principal + 4 
autres. Il n'y a pas d'optimisations faites afin de garder cet exemple aussi petit et 
clair que possible. Mais probablement qu'on pourrait le rendre plus rapide. Mon CPU 
a 4 cœurs, c'est pourquoi OpenMP a démarré exactement 4 threads. 


En regardant la table des statistiques, nous voyons clairement comment la boucle 
a été découpée en 4 parties égales. Oui bon, presque égales, si nous ne tenons pas 
compte du dernier bit. 


Il y a aussi des pragmas pour les operations atomiques.. 


Voyons comment ce code est compilé: 


#pragma omp atomic 
checked++; 


#pragma omp critical 
if ((checked % 100000)==0) 
printf ("checked=%d\n", checked); 


Listing 3.127 : MSVC 2012 


push edi 
push OFFSET checked 
call vcomp atomic add i4 
; Line 55 
push OFFSET $vcomp$critsect$ 
call vcomp enter critsect 


add esp, 12 
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; Line 56 
mov ecx, DWORD PTR _checked 
mov eax, ecx 
cdq 
mov esi, 100000 ; 000186a0H 
idiv esi 
test edx, edx 
jne SHORT $LN1Gcheck nonc 
; Line 57 
push ecx 
push OFFSET ?? Ca OM@NPNHLIOO@checked?$DN?$CFd?6?$AAQ@ 
call _printf 
pop ecx 
pop ecx 


$LN1Gcheck nonc: 
push DWORD PTR  $vcomp$critsect$ 
call vcomp leave critsect 
pop ecx 


Il semble que la fonction vcomp atomic add i4() dans vcomp*.dll soit juste une 
minuscule fonction avec l'instruction LOCK XADD9? dedans. 


vcomp enter critsect() appelle finalement la fonction de l'API win32 
EnterCriticalSection() 9!. 


3.29.2 GCC 


GCC 4.8.1 produit un programme qui montre exactement la méme table de statis- 
tique, 


donc, l'implémentation de GCC divise la boucle en parties de la méme maniére. 


Listing 3.128 : GCC 4.8.1 


mov edi, OFFSET FLAT:main. omp fn.0 
call GOMP parallel start 

mov edi, 0 

call main. omp fn.0 


call GOMP parallel end 


Contrairement à l'implémentation de MSVC, ce que le code de GCC fait est de dé- 
marrer 3 threads et lance la quatriéme dans le thread courant. Il y a donc 4 threads 
au lieu de 5 dans MSVC. 


Voici les fonctions main. omp fn.0: 


Listing 3.129 : GCC 4.8.1 


main. omp fn.0: 
push rbp 
mov rbp, rsp 


60En savoir plus sur le préfixe LOCK: .1.6 on page 1330 
61Vous pouvez en lire plus sur les sections critiques ici: 6.5.4 on page 1026 
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push rbx 
sub rsp, 40 
mov QWORD PTR [rbp-40], rdi 
call omp get num threads 
mov ebx, eax 
call omp get thread num 
mov esi, eax 
mov eax, 2147483647 ; Ox7FFFFFFF 
cdq 
idiv ebx 
mov ecx, eax 
mov eax, 2147483647 ; Ox7FFFFFFF 
cdq 
idiv ebx 
mov eax, edx 
cmp esi, eax 
jl .L15 
.L18: 
imul esi, ecx 
mov edx, esi 
add eax, edx 
lea ebx, [rax+rcx] 
cmp eax, ebx 
jge .L14 
mov DWORD PTR [rbp-20], eax 
.L17: 
mov eax, DWORD PTR [rbp-20] 
mov edi, eax 
call check nonce 
add DWORD PTR [rbp-20], 1 
cmp DWORD PTR [rbp-20], ebx 
jl .L17 
jmp .L14 
.L15: 
mov eax, 0 
add ecx, 1 
jmp .L18 
.L14: 
add rsp, 40 
pop rbx 
pop rbp 
ret 


Ici nous voyons la division clairement: en appelant 
omp get num threads() et omp get thread num() 


nous obtenons le nombre de threads lancés, le nombre courant de threads, et ainsi 
détermine l'intervalle de la boucle. Ensuite nous lancons check nonce(). 


GCC a également inséré l'instruction LOCK ADD directement dans le code, contraire- 
ment à MSVC, qui génére un appel à une fonction DLL séparée: 


Listing 3.130 : GCC 4.8.1 
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lock add DWORD PTR checked[rip], 1 
call GOMP_critical_start 

mov ecx, DWORD PTR checked[ rip] 

mov edx, 351843721 

mov eax, ecx 

imul edx 

sar edx, 13 

mov eax, ecx 

sar eax, 31 

sub edx, eax 

mov eax, edx 

imul eax, eax, 100000 

sub ecx, eax 

mov eax, ecx 

test eax, eax 

jne .L7 

mov eax, DWORD PTR checked[rip] 

mov esi, eax 

mov edi, OFFSET FLAT:.LC2 ; "checked=%d1n" 
mov eax, 0 


call printf 
L7: 
call GOMP critical end 


Les fonctions préfixées par GOMP sont de la bibliothéque GNU OpenMP. Contraire- 
ment à vcomp*.dll, son code source est librement disponible: GitHub. 


3.30 Division signée en utilisant des décalages 


La division non signée par des nombres 2” est facile, il sufft d'utiliser le décalage de 
n bit à droite. La division signée par 2" est aussi facile, mais des corrections doivent 
étre faites avant ou aprés l'opération de décalage. 


D'abord, la plupart des architectures CPU supportent deux opérations de décalage 
à droite: logique et arithmétique. Lors d'un décalage logique à droite, le bit libre 
est mis à zéro. C'est SHR en x86. Lors d'un décalage arithmétique à droite, le bit à 
gauche est mis avec celui qui était à cette position avant le décalage. Ainsi, le signe 
est conservé lors du décalage. C'est SAR en x86. 


Il est intéressant de noter qu'il n'y a pas d'instruction spéciale pour le décalage 
arithmétique à gauche, car il fonctionne tout simplement comme le décalage logique. 
Donc, les instructions SAL et SHL en x86 sont mappées sur le méme opcode. De 
nombreux désassembleurs ne connaissent méme pas l'instruction SAL et la décode 
comme SHL. 


De ce fait, le décalages arithmétique à droite est utilisé pour les nombres signés. 
Par exemple, si vous décalez -4 (11111100b) d'1 bit à droite, l'opération de décalage 
logique produira 01111110b, qui est 126. Le décalage arithmétique à droite produira 
11111110b, qui est -2. Jusqu'ici, tout va bien. 


Et si nous devons diviser -5 par 2? Ca vaut 2,5 ou juste -2 en arithmétique entiére. -5 
est 11111011b, en décalant cette valeur de 1 bit à droite, nous obtenons 11111101b, 
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qui est -3. Ceci est légérement incorrect. 


Un autre exemple: - = -0.5 ou 0 en arithmétique entière. Mais -1 est 11111111b, 
et 11111111b » 1 = 11111111b, qui est encore -1. Ceci est aussi incorrect. 


Une solution est d'ajouter 1 à la valeur en entrée si elle est négative. 


C'est pourquoi, si nous compilons l'expression x/2, oü x est un signed int, GCC 4.8 
produira quelque chose comme cela: 


mov eax, edi 

shr eax, 31 ; isoler le bit le plus à gauche, qui est 1 si la 
valeur est négative et 0 si elle est positive 

add eax, edi ; ajouter 1 à la valeur en entrée si elle est 
négative, ne rien faire autrement 

sar eax ; décalage arithmétique à droite de un bit 

ret 


Si vous divisez par 4, il faut ajouter 3 à la valeur en entrée si elle est négative. Donc 
ceci est ce que GCC 4.8 génére pour x/4 : 


lea eax, [rdi+3] ; préparer la valeur x43 en avance 
test edi, edi 


; Si le signe n'est pas négatif (i.e., positif), déplacer la valeur 
en entrée dans EAX | | "M 

; Si le signe est négatif, la valeur x+3 est laissée telle quelle 
dans EAX f 

cmovns eax, edi 

; effectuer un décalage arithmétique à droite de 2 bits 

sar eax, 2 

ret 


Si vous divisez par 8, il faut ajouter 7 à la valeur en entrée, etc. 


MSVC 2013 est légèrement différent. Ceci est la division par 2: 


mov eax, DWORD PTR a$[esp-4] 

; étendre la valeur d'entrée à 64-bit dans EDX:EAX 

; concrètement, cela signifie que EDX sera mis à OFFFFFFFFh si la 
valeur en entrée est négative 

; ... où à Q si elle est positive 

cdq 

; soustraire -1 de la valeur en entrée si elle est négative 

; ceci est la même chose qu'ajouter 1 


sub eax, edx 

; effectuer le décalage arithmétique à droite 
sar eax, 1 

ret 0 


La division par 4 dans MSVC 2013 est encore plus complexe: 


mov eax, DWORD PTR a$[esp-4] 
cdq 


; maintenant EDX contient OFFFFFFFFh si la valeur en entrée est 
négative 
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; EDX contient O si elle est positive 


and edx, 3 
; maintenant EDX contient 3 si la valeur en entrée est négative et 0 
autrement 


; ajouter 3 à la valeur en entrée si elle est négative ou ne rien 
faire autrement: 
dd 


eax, edx 
; effectuer le décalage arithmétique à droite 
sar eax, 2 
ret 0 


La division par 8 dans MSVC 2013 est similaire, mais 3 bits de EDX sont pris au lieu 
de 2, produisant une correction de 7 au lieu de 3. 


Parfois, Hex-Rays 6.8 ne gére pas correctement un tel code, et il peut produire 
quelque chose comme ceci: 


int v0; 


|. int64 v14 


v14 = ...; 
v0 = ((signed int)v14 - HIDWORD(v14)) >> 1; 


...ce qui peut sans risque être récrit en vO=v14/2. 


Hex-Rays 6.8 peut aussi gérer les divisions signées par 4 comme cela: 


result = ((BYTE4(v25) € 3) + (signed int)v25) >> 2; 


...peut être récrit en v25 / 4. 


En outre, une telle correction est souvent utilisé lorsque la division est remplacée par 
la multiplication par des nombres magiques : lire Mathematical Recipes^?à propos 
de la multiplication inverse. Et parfois, un décalage additionnel est utilisé aprés la 
multiplication. Par exemple, lorsque GCC optimise +, il ne peut pas trouver la mul- 
tiplication inverse pour 10, car l'équation diophantienne n'a pas de solution. Donc 
il génère du code pour Ẹ et puis ajoute une opération de décalage arithmétique a 
droite de 1 bit, pour diviser le résultat par 2. Bien sdr, ceci est seulement vrai pour 
les entiers signés. 


Donc, voici la division par 10 de GCC 4.8: 


mov eax, edi 
mov edx, 1717986919 ; nombre magique 
sar edi, 31 ; isoler le bit le plus à gauche (qui refléte 
le signe) 
imul edx ; multiplication par le nombre magique (calculer 
x/5 
a edx, 2 ; mainenant calculer (x/5)/2 


62https://math. recipes 
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; soustraire -1 (ou ajouter 1) si la valeur en entrée est négative 
; ne rien faire autrement 


sub edx, edi 
mov eax, edx 
ret 


Résumé: 2” - 1 doit étre ajouté à la valeur en entrée avant un décalage arithmétique, 
ou il faut ajouter 1 au résultat final aprés le décalage. Les deux opérations sont 
équivalentes l'une à l'autre, donc les développeurs du compilateur doivent choisir ce 
qui est la plus adapté pour eux. Du point de vue du rétro-ingénieur, cette correction 
est une preuve manifeste que la valeur a un type signé. 


3.31 Un autre heisenbug 


Parfois, un tableau (ou tampon) peut déborder à cause d'une erreur de poteaux et 
d'intervalles : 


#include <stdio.h> 


int array1[128]; 

int important_varl; 
int important_var2; 
int important_var3; 
int important_var4; 
int important_var5; 


int main() 
{ 
important_varl=1; 
important_var2=2; 
important_var3=3; 
important var4-4; 
important var5-5; 


array1[0]=123; 
array1[128]2456; // BUG 


"important _varl=%d\n", important_varl); 


printf ( 5 
printf ("important var2=%d\n", important var2); 
printf ("important var3=%d\n", important var3); 
( ) 
( ) 


D 


printf ("important var4=%d\n", important var4 
printf ("important var5=%d\n", important var5 


, 


}; 


Ceci est ce que ce programme a affiché dans mon cas (GCC 5.4 x86 sans optimisation 
sur Linux) : 


important varl-1 
important var2-456 
important var3-3 
important var4-4 
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| important_var5=5 


Lorsque ca se produit, important_var2 avait été mise par le compilateur juste aprés 
arrayl[]: 


Listing 3.131 : objdump -x 


0804a040 g O .bss 00000200 arrayl 

0804a240 g O .bss 00000004 important_var2 
0804a244 g O .bss 00000004 important_var4 
0804a248 g O .bss 00000004 important_varl 
0804a24c y O .bss 00000004 important_var3 
0804a250 g O .bss 00000004 important_var5 


D'autres compilateurs peuvent arranger les variables dans un autre ordre, et une 
autre variable sera écrasée. Ceci est aussi un heisenbug (3.28.2 on page 822)—bug 
qui peut se produire ou passer inaperçu suivant la version du compilateur et les 
options d'optimisation. 


Si toutes les variables et tableaux sont allouées sur la pile locale, la protection de la 
pile peut être déclenchée, ou pas. Toutefois, Valgrind peut trouver ce genre de bugs. 


Un exemple connexe dans le livre (jeu Angband) : 1.27 on page 389. 


3.32 Le cas du return oublié 

Revoyons la partie “tentative d'utiliser le résultat d'une fonction renvoyant void”: 
1.15.1 on page 145. 

Ceci est un bug que j'ai rencontré une fois. 


Et c'est encore une autre démonstration de la façon dont C/C++ met les valeurs de 
retour dans le registre EAX/RAX. 


Dans ce bout de code, j'ai oublié d'ajouter return : 


#include <stdio.h> 
#include <stdlib.h> 


struct color 


{ 
int R; 
int G; 
int B; 
}; 


struct color* create color (int R, int G, int B) 


{ 


struct color* rt=(struct color*)malloc(sizeof(struct color) ); 


rt->R=R; 
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rt->G=G; 
rt->B=B; 
// must be "return rt;" here 
}; 
int main() 
1 
struct color* a=create color(1,2,3); 
printf ("sd %d %d\n", a->R, a->G, a->B); 
}; 


GCC 5.4 sans optimisation le compile silencieusement, sans avertissement. Et le 
code fonctionne! Voyons pourquoi: 


Listing 3.132 : GCC 5.4 sans optimisation 


create color: 


push rbp 

mov rbp, rsp 

sub rsp, 32 

mov DWORD PTR [rbp-20], edi 
mov DWORD PTR [rbp-24], esi 
mov DWORD PTR [rbp-28], edx 
mov edi, 12 

call malloc 


; RAX = pointer to newly allocated buffer 
; now fill it with R/G/B: 


mov QWORD PTR [rbp-8], rax 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-20] 
mov DWORD PTR [rax], edx 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-24] 
mov DWORD PTR [rax+4], edx 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-28] 
mov DWORD PTR [rax+8], edx 
nop 
leave 

; RAX hasn't been modified till that point! 
ret 


Si j'ajoute return rt;, seule une instruction est ajoutée à la fin, qui est redondante: 


Listing 3.133 : GCC 5.4 sans optimisation 


create color: 


push rbp 

mov rbp, rsp 

sub rsp, 32 

mov DWORD PTR [rbp-20], edi 
mov DWORD PTR [rbp-24], esi 
mov DWORD PTR [rbp-28], edx 


mov edi, 12 
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call malloc 
; RAX = pointer to buffer 
mov QWORD PTR [rbp-8], rax 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-20] 
mov DWORD PTR [rax], edx 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-24] 
mov DWORD PTR [rax+4], edx 
mov rax, QWORD PTR [rbp-8] 
mov edx, DWORD PTR [rbp-28] 
mov DWORD PTR [rax+8], edx 
; reload pointer to buffer into RAX again, and this is redundant operation... 
mov rax, QWORD PTR [rbp-8] ; new instruction 
leave 
ret 


Des bogues de ce type sont trés dangereux, parfois ils apparaissent, parfois ils res- 
tent invisibles. 


Maintenant, j'essaye GCC avec l'optimisation: 


Listing 3.134 : GCC 5.4 avec optimisation 


create color: 


rep ret 

main: 
xor eax, eax 

; as if create color() was called and returned 0 
sub rsp, 8 
mov r8d, DWORD PTR ds:8 
mov ecx, DWORD PTR [rax+4] 
mov edx, DWORD PTR [rax] 
mov esi, OFFSET FLAT: .LC1 
mov edi, 1 
call . printf chk 
xor eax, eax 
add rsp, 8 
ret 


Le compilateur en déduit que rien n'est renvoyé de la fonction, donc il optimise en 
enlevant complétement la fonction. Et il suppose que O est renvoyé par défaut. Le 
zéro est utilisé comme une adresse sur une structure dans main().. Bien sûr, ce code 
plante. 


GCC en mode C++ est aussi silencieux à propos de cela. 
Essayons MSVC 2015 x86 sans optimisation. Il averti à propos de ce probléme: 


c:\tmp\3.c(19) : warning C4716: 'create color': must return a value 


Et il génére du code qui plante: 
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Listing 3.135 : MSVC 2015 x86 sans optimisation 


_rt$ = -4 

_R$ = 8 

_G$ = 12 

_B$ = 16 

_create color PROC 
push ebp 
mov ebp, esp 
push ecx 
push 12 
call _malloc 

; EAX = pointer to buffer 
add esp, 4 
mov DWORD PTR rt$[ebp], eax 
mov eax, DWORD PTR rt$[ebp] 
mov ecx, DWORD PTR R$[ebp] 
mov DWORD PTR [eax], ecx 
mov edx, DWORD PTR _rt$[ebp] 
mov eax, DWORD PTR G$[ebp] 

; EAX is set to G argument: 
mov DWORD PTR [edx+4], eax 
mov ecx, DWORD PTR _rt$[ebp] 
mov edx, DWORD PTR B$[ebp] 
mov DWORD PTR [ecx+8], edx 
mov esp, ebp 
pop ebp 

; EAX = G at this point: 
ret 0 


Create color ENDP 


Maintenant MSVC 2015 x86 avec optimisation, qui génére du code qui plante aussi 


mais pour une raison différente. 


Listing 3.136 : MSVC 2015 x86 avec optimisation 


_a$ = -4 
_main PROC 
; this is inlined optimized version of create color): 
push ecx 
push 12 
call _malloc 
mov DWORD PTR [eax], 1 
mov DWORD PTR [eax+4], 2 
mov DWORD PTR [eax+8], 3 


; EAX points to allocated buffer, and it's filled, OK 
; now we reload pointer to buffer, hoping it's in "a" variable 
; but inlined function didn't store pointer to "a" variable! 
mov eax, DWORD PTR _a$[esp+8] 
; EAX = some random garbage at this point 
push DWORD PTR [eax+8] 
push DWORD PTR [eax+4] 
push DWORD PTR [eax] 
push OFFSET $SG6074 
call _ printf 
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xor 

add 

ret 
main  ENDP 


8 
12 
16 


O 
X 
uou M 


eax, eax 
esp, 24 
0 


create color PROC 


push 
call 
mov 
add 
mov 
mov 
mov 
mov 
mov 


12 

_malloc 

ecx, DWORD PTR R$[esp] 
esp, 4 

DWORD PTR [eax], ecx 

ecx, DWORD PTR G$[esp-4] 
DWORD PTR [eax+4], ecx 
ecx, DWORD PTR _B$[esp-4] 
DWORD PTR [eax+8], ecx 


; EAX points to allocated buffer, OK 


ret 


0 


Create color ENDP 


Toutefois, MSVC 2015 x64 sans optimisation génére du code qui fonctionne: 


Listing 3.137 : MSVC 2015 x64 sans optimisation 


O 
X 
Woo ol 
N 
N 


create color PROC 


mov 
mov 
mov 
sub 
mov 
call 


DWORD PTR [rsp+24], r8d 
DWORD PTR [rsp+16], edx 
DWORD PTR [rsp+8], ecx 
rsp, 56 
ecx, 12 
malloc 


; RAX = allocated buffer 


mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
add 


QWORD PTR rt$[rsp], rax 
rax, QWORD PTR rt$[rsp] 
ecx, DWORD PTR R$[rsp] 
DWORD PTR [rax], ecx 
rax, QWORD PTR rt$[rsp] 
ecx, DWORD PTR G$[rsp] 
DWORD PTR [rax+4], ecx 
rax, QWORD PTR rt$[rsp] 
ecx, DWORD PTR B$[rsp] 
DWORD PTR [rax+8], ecx 
rsp, 56 


; RAX didn't change down to this point 


ret 


0 


create color ENDP 
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MSVC 2015 x64 avec optimisation met le fonction en ligne, comme dans le cas du 
x86, et le code résultant plante. 


Ceci est un morceau de code réel de ma bibliotheque octothorpe, qui fonctionnait 
et dont tous les tests réussissaient. C'était ainsi, sans return pendant un certain 
temps.. 


uint32 t LPHM u32 hash(void *key) 
1 


} 


jenkins one at a time hash u32((uint32 t)key); 


La morale de l'histoire: les warnings sont trés importants, utilisez -Wall, etc, etc... 
Lorsque la déclaration return est absente, le compilateur peut simplement silen- 
cieusement ne rien faire à ce point. 


Un tel bug passé inapercu peut gácher une journée. 


Aussi, le débogage shotgun est mauvais, car encore une fois, un tel bogue peut 
passer inaperçu ("tout fonctionne maintenant, qu'il en soit ainsi, laissons tout ca 
comme c'est"). 


Voir aussi: la discussion sur Hacker News?” et l'article de blog archivée*?. 


3.33 Exercice: un peu plus loin avec les pointeur et 
les unions 

Ce code a été copié/collé de dwm® , probablement le plus petit window manager sur 

Linux de tous les temps. 


Le probléme: les frappes de l'utilisateur au clavier doivent étre réparties aux diverses 
fonctions de dwm. Ceci est en général résolu en utilisant un gros switch(). 


En général, c'est un probléme important qui doit étre résolu par tous développeur 
de jeu vidéo. 


Apparemment, le créateur de dwm a voulu rendre le code soigné et modifiable par 
les utilisateurs: 


typedef union { 
int i; 
unsigned int ui; 
float f; 
const void *v; 


63https://news.ycombinator.com/item?id=18671609 
%https://web.archive.org/web/20190317231721/https://yurichev.com/blog/no_return/ 
65https://dwm.suckless.org/ 


839 


) Arg; 


typedef struct { 
unsigned int mod; 
KeySym keysym; 
void (*func)(const Arg *); 
const Arg arg; 
} Key; 


static Key keys[] = { 


/* modifier key function argument */ 
{ MODKEY, XK_p, spawn, {.v = dmenucmd } }, 
{ MODKEY|ShiftMask, XK Return, spawn, {.v = termcmd } }, 
{ MODKEY, XK_b, togglebar, {0} }, 
{ MODKEY, XK j, focusstack, {.i = +1 } }, 
{ MODKEY, XK_k, focusstack, {.i = -1 } }, 
{ MODKEY, XK_i, incnmaster, {.i = +1 } }, 
{ MODKEY, XK d, incnmaster, {.i = -1 } }, 
{ MODKEY, XK_h, setmfact, {.f = -0.05} }, 
{ MODKEY, XK 1, setmfact, {.f = 40.05) $, 
{ MODKEY, XK Return, zoom, (0) $, 
{ MODKEY, XK_Tab, view, {0} }, 
{ MODKEY|ShiftMask, XK c, killclient, {0} Y, 
{ MODKEY, XK t, setlayout, {.v = &layouts[0]} }, 
{ MODKEY, XK_f, setlayout, {.v = &layouts[1]} }, 
{ MODKEY, XK_m, setlayout, {.v = &layouts[2]} }, 
void 
spawn(const Arg *arg) 
{ 
void 
focusstack(const Arg *arg) 
{ 


Pour chaque touche frappée (ou raccourci), une fonction est définie. Encore mieux: 
un paramétre (ou argument) peut étre passé a une fonction dans chaque cas. Mais 
les paramétres peuvent avoir des types variés. Donc une union est utilisée ici. Une 
valeur du type requis est mise dans la table. Chaque fonction prend ce dont elle a 
besoin. 


A titre d’exercice, essayez d’écrire un code comme cela, ou plongez-vous dans dwm 
et voyez comment l'union est passée aux fonctions et est gérée. 
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3.34 Windows 16-bit 


Les programmes Windows 16-bit sont rares de nos jours, mais ils peuvent étre utilisés 
dans le cadre de rétrocomputing ou d'hacking de dongle (8.8 on page 1081). 


Il y a eu des versions 16-bit de Windows jusqu'à la 3.11. 95/98/ME supportaient le 
code 16-bit, ainsi que les versions 32-bit de la série Windows NT. Les versions 64-bit 
de Windows NT ne supportaient pas du tout le code exécutable 16-bit. 


Le code ressemble a du code MS-DOS. 
Les fichiers exécutables sont du type NE (appelé «new executable »). 


Tous les exemples considérés ici ont été compilés avec le compilateur OpenWatcom 
1.9, en utilisant ces paramétres: 


wcl.exe -i=C:/WATCOM/h/win/ -s -os -bt=windows -bcl=windows example.c 


3.34.1 Exemple#1 


#include «windows.h» 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 


1 
MessageBeep(MB ICONEXCLAMATION); 
return 0; 
}; 
WinMain proc near 
push bp 
mov bp, sp 
mov ax, 30h ; '0' ; MB_ICONEXCLAMATION constant 
push ax 
call MESSAGEBEEP 
xor ax, ax ; return 0 
pop bp 
retn OAh 
WinMain endp 


Ca semble facile, jusqu'ici. 


3.34.2 Exemple #2 


#include «windows.h» 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 


841 


LPSTR lpCmdLine, 
int nCmdShow ) 


1 
MessageBox (NULL, "hello, world", "caption", MB YESNOCANCEL) ; 
return 0; 
}; 
WinMain proc near 
push bp 
mov bp, sp 
xor ax, ax ; NULL 
push ax 
push ds 
mov ax, offset aHelloWorld ; 0x18. "hello, world" 
push ax 
push ds 
mov ax, offset aCaption ; 0x10. "caption" 
push ax 
mov ax, 3 ; MB YESNOCANCEL 
push ax 
call MESSAGEBOX 
xor ax, ax ; return 0 
pop bp 
retn OAh 
WinMain endp 
dseg02:0010 aCaption db 'caption',0 
dseg02:0018 aHelloWorld db ‘hello, world',0 


Quelques points importants ici: la convention d'appel PASCAL impose de passer le 
premier argument en premier (MB YESNOCANCEL), et le dernier argument — en der- 
nier (NULL). Cette convention demande aussi à l'appelant de restaurer le pointeur 
de pile : D'où l'instruction RETN qui a OAh comme argument, ce qui implique que 
le pointeur sera incrémenté de 10 octets lorsque l'on sortira de la fonction. C'est 
comme stdcall (6.1.2 on page 953), mais les arguments sont passés dans l'ordre 
«naturel ». 


Les pointeurs sont passés par paire: d'abord le segment de données, puis le pointeur 
dans le segment. Il y a seulemnt un segment dans cet exemple, donc DS pointe 
toujours sur le segment de données de l'exécutable. 


3.34.3 Exemple +3 


#include «windows.h» 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 


int result=MessageBox (NULL, "hello, world", "caption", MB YESNOCANCEL) 7 
Ga 
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if (result==IDCANCEL) 

MessageBox (NULL, "you pressed cancel", "caption", MB OK); 
else if (result--IDYES) 

MessageBox (NULL, "you pressed yes", "caption", MB OK); 
else if (result--IDNO) 

MessageBox (NULL, "you pressed no", "caption", MB OK); 


return 0; 
}; 
WinMain proc near 
push bp 
mov bp, sp 
xor ax, ax ; NULL 
push ax 
push ds 
mov ax, offset aHelloWorld ; "hello, world" 
push ax 
push ds 
mov ax, offset aCaption ; "caption" 
push ax 
mov ax, 3 ; MB YESNOCANCEL 
push ax 
call MESSAGEBOX 
cmp ax, 2 ; IDCANCEL 
jnz short loc 2F 
xor ax, ax 
push ax 
push ds 
mov ax, offset aYouPressedCanc ; "you pressed cancel" 
jmp short loc 49 
loc 2F: 
cmp ax, 6 ; IDYES 
jnz short loc 3D 
xor ax, ax 
push ax 
push ds 
mov ax, offset aYouPressedYes ; "you pressed yes" 
jmp short loc 49 
loc 3D: 
cmp ax, 7 ; IDNO 
jnz short loc 57 
xor ax, ax 
push ax 
push ds 
mov ax, offset aYouPressedNo ; "you pressed no" 
loc 49: 
push ax 
push ds 
mov ax, offset aCaption ; "caption" 
push ax 
xor ax, ax 
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push ax 

call MESSAGEBOX 
loc 57: 

xor ax, ax 

pop bp 

retn OAh 
WinMain endp 


Exemple un peu plus long de la section précédente. 


3.34.4 Exemple +4 


#include «windows.h» 


int PASCAL funcl (int a, int b, int c) 


1 
return a*b+c; 
long PASCAL func2 (long a, long b, long c) 
1 
return a*b+c; 
}; 
long PASCAL func3 (long a, long b, long c, int d) 
1 
return a*b+c-d; 
Fi 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 


{ 
funcl (123, 456, 789); 
func2 (600000, 700000, 800000); 
func3 (600000, 700000, 800000, 123); 
return 0; 
}; 
funcl proc near 
[o - word ptr 4 
b = word ptr 6 
a = word ptr 8 
push bp 
mov bp, sp 
mov ax, [bpta] 
imul [bp+b] 
add ax, [bp+c] 


pop bp 
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funci 
func2 


arg 0 
arg 2 
arg 4 
arg 6 
arg 8 
arg A 


func2 
func3 


arg_0 
arg_2 
arg_4 
arg_6 
arg_8 
arg_A 
arg C 


retn 6 

endp 

proc near 
word ptr 4 
word ptr 6 
word ptr 8 


word ptr OAh 
word ptr OCh 
word ptr OEh 


push bp 
mov bp, sp 
mov ax, [bp+arg_8] 
mov dx, [bp+arg A] 
mov bx, [bp+arg_4] 
mov cx, [bp+arg 6] 
call sub B2 ; long 32-bit multiplication 
add ax, [bp+arg_0] 
adc dx, [bp+arg 2] 
pop bp 
retn 12 
endp 
proc near 

word ptr 4 

word ptr 6 

word ptr 8 


word ptr OAh 
word ptr OCh 
word ptr OEh 
word ptr 10h 


push bp 

mov bp, sp 

mov ax, [bp+arg A] 

mov dx, [bp+arg C] 

mov bx, [bp+arg 6] 

mov cx, [bp+arg 8] 

call sub B2 ; long 32-bit multiplication 

mov cx, [bp+arg 2] 

add CX, ax 

mov bx, [bp+arg_4] 

adc bx, dx ; BX=high part, CX=low part 
mov ax, [bp+arg 0] 

cwd ; AX=low part d, DX=high part d 
sub CX, ax 

mov ax, cx 

sbb bx, dx 

mov dx, bx 


pop bp 
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retn 14 
func3 endp 
WinMain proc near 
push bp 
mov bp, sp 
mov ax, 123 
push ax 
mov ax, 456 
push ax 
mov ax, 789 
push ax 
call funcl 
mov ax, 9 ; high part of 600000 
push ax 
mov ax, 2/C0h ; low part of 600000 
push ax 
mov ax, OAh ; high part of 700000 
push ax 
mov ax, OAE60h ; low part of 700000 
push ax 
mov ax, OCh ; high part of 800000 
push ax 
mov ax, 3500h ; low part of 800000 
push ax 
call func2 
mov ax, 9 ; high part of 600000 
push ax 
mov ax, 2/C0h ; low part of 600000 
push ax 
mov ax, OAh ; high part of 700000 
push ax 
mov ax, OAE60h ; low part of 700000 
push ax 
mov ax, OCh ; high part of 800000 
push ax 
mov ax, 3500h ; low part of 800000 
push ax 
mov ax, 7Bh 123 
push ax 
call func3 
xor ax, ax ; return 0 
pop bp 
retn OAh 
WinMain endp 


Les valeurs 32-bit (le type de donnée long implique 32 bits, tandis que int est 16-bit 
en code 16-bit (à la fois pour MS-DOS et Win16) sont passées par paires. C'est tout 
comme lorsqu'une valeur 64-bit est utilisée dans un environnement 32-bit (1.34 on 
page 509). 


sub B2 voici une fonction de bibliothéques écrite par les développeurs du compi- 
lateurs qui fait la «multiplication des long» (i.e., multiplie deux valeurs 32-bits). 


846 
D'autres fonctions de compilateur qui font la méme chose sont listées ici: .5 on 
page 1354, .4 on page 1354. 


La paire d'instructions ADD/ADC est utilisée pour l'addition de valeurs composées: ADD 
peut mettre le flag CF à 0/1, et ADC l'utilise aprés. 


La paire d'instructions SUB/SBB est utilisée pour la soustraction: SUB peut mettre la 
flag CF à 0/1, et SBB l'utilise aprés. 


Les valeurs 32-bit sont renvoyées de la fonction dans la paire de registres DX:AX. 
Les constantes sont aussi passées par paires dans WinMain() ici. 


La constante 123 typée int est d'abord converti suivant le signe de la valeur 32-bit 
en utilisant l'instruction CWD. 


3.34.5 Exemple #5 


#include «windows.h» 


int PASCAL string compare (char *s1, char *s2) 


1 
while (1) 
1 
if (*s1!=*s2) 
return 0; 
if (*sl==0 || *s2==0) 
return 1; // end of string 
s1++; 
S2++; 
}; 
}; 
int PASCAL string compare far (char far *s1, char far *s2) 
1 
while (1) 
1 
if (*s1!=*s2) 
return 0; 
if (*sl==0 || *s2==0) 
return 1; // end of string 
s1++; 
S2++; 
}; 
}; 
void PASCAL remove digits (char *s) 
{ 
while (*s) 
{ 


if (*s>='0' && *s<='9') 


*s="-'; 
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S++; 
}; 
un 


char str[]="hello 1234 world"; 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 


1 
string compare ("asd", "def"); 
string compare far ("asd", "def"); 
remove digits (str); 
MessageBox (NULL, str, "caption", MB YESNOCANCEL) ; 
return 0; 
}; 


string compare proc near 


arg_0 = word ptr 4 
arg 2 = word ptr 6 
push bp 
mov bp, sp 
push si 
mov si, [bp+arg 0] 
mov bx, [bp+arg 2] 
loc 12: ; CODE XREF: string compare+21)j 
mov al, [bx] 
cmp al, [sil 
jz short loc 1C 
xor ax, ax 
jmp short loc 2B 


loc 1C: ; CODE XREF: string compare+Ej 
test al, al 


jz short loc 22 
jnz short loc 27 
loc 22: ; CODE XREF: string compare+16)j 
mov ax, 1 
jmp short loc 2B 


loc 27: ; CODE XREF: string compare+18)j 
inc bx 
inc si 
jmp short loc 12 
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loc 2B: ; 
pop 
pop 
retn 


CODE XREF: string compare-12j 
string compare-1Dj 

si 

bp 

4 


string compare endp 


WinMain+18p 


string compare far proc near ; CODE XREF: 
arg 0 = word ptr 4 
arg 2 = word ptr 6 
arg 4 - word ptr 8 
arg 6 = word ptr OAh 
push bp 
mov bp, sp 
push si 
mov si, [bp+arg 0] 
mov bx, [bp+arg 4] 
loc 3A: ; CODE XREF: string compare far+35j 
mov es, [bp+arg 6] 
mov al, es:[bx] 
mov es, [bp+arg 2] 
cmp al, es: [si] 
jz short loc 4C 
xor ax, ax 
jmp short loc_67 
loc 4C: ; CODE XREF: string compare far+16j 
mov es, [bp+arg 6] 
cmp byte ptr es:[bx], 0 
jz short loc_5E 
mov es, [bp+arg 2] 
cmp byte ptr es:[sil, O 
jnz short loc 63 
loc 5bE: ; CODE XREF: string compare far-23j 
mov ax, 1 
jmp short loc 67 
loc 63: ; CODE XREF: string compare far+2Cj 
inc bx 
inc si 
jmp short loc_3A 
loc 67: ; CODE XREF: string compare far-1Aj 
; String compare far+31)j 
pop si 
pop bp 
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retn 8 
string compare far endp 


remove digits proc near ; CODE XREF: WinMain+1Fp 


arg 0 = word ptr 4 


push bp 
mov bp, sp 
mov bx, [bp+arg 0] 
loc 72: ; CODE XREF: remove digits+18j 
mov al, [bx] 
test al, al 
jz short loc 86 
cmp al, 30h ; '0' 
jb short loc 83 
cmp al, 39h ; '9' 
ja short loc 83 
mov byte ptr [bx], 2Dh ; '-' 


loc 83: ; CODE XREF: remove digits+Ej 
; remove digits+12j 
inc bx 
jmp short loc 72 


loc 86: ; CODE XREF: remove digits+Aj 
pop bp 
retn 2 

remove digits endp 


WinMain proc near ; CODE XREF: start+EDp 


push bp 

mov bp, sp 

mov ax, offset aAsd ; "asd" 
push ax 

mov ax, offset aDef ; "def" 
push ax 

call string compare 

push ds 

mov ax, offset aAsd ; "asd" 
push ax 

push ds 

mov ax, offset aDef ; "def" 
push ax 

call string compare far 

mov ax, offset aHellol234World ; "hello 1234 world" 
push ax 

call remove digits 

xor ax, ax 

push ax 


push ds 
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mov ax, Offset aHellol234World ; "hello 1234 world" 
push ax 

push ds 

mov ax, offset aCaption ; "caption" 
push ax 

mov ax, 3 ; MB YESNOCANCEL 

push ax 

call MESSAGEBOX 

xor ax, ax 

pop bp 

retn OAh 


WinMain endp 


Nous voyons ici une différence entre les pointeurs appelés «near » et «far» : un autre 
effet bizarre de la mémoire segmentée en 16-bit 8086. 


Vous pouvez en lire plus à ce sujet ici: ?? on page ??. 


Les pointeurs «near» sont ceux qui pointent dans le segment de données courant. 
C'est pourquoi la fonction string compare() prend seulement deux pointeurs 16- 
bit, et accede des données dans le segment sur lequel DS pointe (L'instruction mov 
al, [bx] fonctionne en fait comme mov al, ds:[bx]—DS est implicite ici). 


Les pointeurs «far » sont ceux qui pointent sur des données dans un autre segment 
de mémoire. C'est pourquoi string compare far() prend la paire de 16-bit comme 
un pointeur, charge la partie haute dans le registre de segment ES et accède aux 
données à travers lui (mov al, es:[bx]). Les pointeurs «far» sont aussi utilisés 
dans mon exemple win16 MessageBox() : 3.34.2 on page 840. En effet, le noyau 
de Windows n'est pas au courant du segment de données qui doit étre utilisé pour 
accéder aux chaînes de texte, donc il a besoin de l'information complète. La raison 
de cette distinction est qu'un programme compact peut n'utiliser qu'un segment de 
données de 64kb, donc il n'a pas besoin de passer la partie haute de l'adresse, qui 
est toujours la méme. Un programme plus gros peut utiliser plusieurs segments de 
données de 64kb, donc il doit spécifier le segment de données à chaque fois. 


C'est la méme histoire avec les segments de code. Un programme compact peut 
avoir tout son code exécutable dans un seul segment de 64kb, donc toutes les fonc- 
tions y seront appelées en utilisant l'instruction CALL NEAR, et le contróle du flux sera 
renvoyé en utilisant RETN. Mais si il y a plusieurs segments de code, alors l'adresse 
d'une fonction devra étre spécifiée par une paire, et sera appelée en utilisant l'ins- 
truction CALL FAR, et le contróle du flux renvoyé en utilisant RETF. 


Ceci est ce qui est mis dans le compilateur en spécifiant le «modéle de mémoire ». 


Les compilateurs qui ciblent MS-DOS et Win16 ont des bibliothéques spécifiques pour 
chaque modéle de mémoire: elles différent par le type de pointeurs pour le code et 
les données. 


3.34.6 Exemple +6 


#include «windows.h» 
#include <time.h> 
#include <stdio.h> 
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char strbuf[256]; 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 


1 
struct tm *t; 
time t unix time; 
unix time-time (NULL); 
t=localtime (&unix time); 
sprintf (strbuf, "%04d-%02d-%02d %02d:%02d:%02d", t->tm_year+1900, 2 
V t->tm_mon, t->tm_mday, 
t->tm_hour, t->tm_min, t->tm_sec); 
MessageBox (NULL, strbuf, "caption", MB OK); 
return 0; 
}; 
WinMain proc near 
var_4 = word ptr -4 
var_2 = word ptr -2 
push bp 
mov bp, sp 
push ax 
push ax 
xor ax, ax 
call time _ 
mov [bp+var_4], ax ; low part of UNIX time 
mov [bp+var_2], dx high part of UNIX time 
lea ax, [bp+var_4] ; take a pointer of high part 
call localtime 
mov bx, ax sb 
push word ptr [bx] second 
push word ptr [bx+2] ; minute 
push word ptr [bx+4] hour 
push word ptr [bx+6] ; day 
push word ptr [bx+8] ; month 
mov ax, [bx+0Ah] ; year 
add ax, 1900 
push ax 
mov ax, offset a04d02d02d02d02 ; 


Er cce A cU 


pus 


mov ax, offset strbuf 
push ax 
call sprintf 


ax 
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add sp, 10h 
xor ax, ax ; NULL 
push ax 
push ds 
mov ax, offset strbuf 
push ax 
push ds 
mov ax, offset aCaption ; "caption" 
push ax 
xor ax, ax ; MB OK 
push ax 
call MESSAGEBOX 
xor ax, ax 
mov sp, bp 
pop bp 
retn OAh 
WinMain endp 


Le temps UNIX est une valeur 32-bit, donc il est renvoyé dans la paire de registres 
DX:AX et est stocké dans deux variables locales 16-bit. Puis, un pointeur sur la 
paire est passé à la fonction localtime(). La fonction localtime() a une struc- 
ture struct tm allouée quelque part dans les entrailles de la bibliothéque C, donc 
seul un pointeur est renvoyé. 


À propos, ceci implique aussi que la fonction ne peut pas étre appelée tant que le 
résultat n'a pas été utilisé. 


Pour les fonctions time() et Localtime(), une convention d'appel Watcom est uti- 
lisée ici: les quatre premiers arguments sont passés dans les registres AX, DX, BX et 
CX, et le reste des arguments par la pile. 


Les fonctions utilisant cette convention sont aussi marquées par un souligné à la fin 
de leur nom. 


sprintf() n'utilise pas la convention d'appel PASCAL, ni la Watcom, 
donc les arguments sont passés de la maniére cdecl normale (6.1.1 on page 953). 


Variables globales 


Ceci est le méme exemple, mais cette fois les variables sont globales: 


#include «windows.h» 
#include <time.h> 
#include <stdio.h> 


char strbuf[256]; 
struct tm *t; 
time t unix time; 


int PASCAL WinMain( HINSTANCE hInstance, 
HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, 
int nCmdShow ) 
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unix time-time (NULL); 
t=localtime (&unix time); 


sprintf (strbuf, "%04d-%02d-%02d %02d:%02d:%02d", t->tm_year+1900, > 
V t->tm_mon, t->tm_mday, 
t->tm_hour, t->tm_min, t->tm_sec); 


MessageBox (NULL, strbuf, "caption", MB OK); 
return 0; 


Fi 


unix time low dw 0 
unix time high dw 0 


t dw 0 

WinMain proc near 
push bp 
mov bp, sp 
xor ax, ax 
call time _ 
mov unix time low, ax 
mov unix time high, dx 
mov ax, offset unix time low 
call localtime 
mov bx, ax 
mov t, ax ; will not be used in future... 
push word ptr [bx] ; Seconds 
push word ptr [bx+2] ; minutes 
push word ptr [bx+4] ; hour 
push word ptr [bx+6] ; day 
push word ptr [bx+8] ; month 
mov ax, [bx+0Ah] ; year 
add ax, 1900 
push ax 
mov ax, offset a04d02d02d02d02 ; 

"%04d -%02d-%02d %02d:%02d:%02d" 

push ax 
mov ax, Offset strbuf 
push ax 
call sprintf_ 
add sp, 10h 
xor ax, ax ; NULL 
push ax 
push ds 
mov ax, offset strbuf 
push ax 
push ds 
mov ax, offset aCaption ; "caption" 
push ax 
xor ax, ax ; MB OK 
push ax 


call MESSAGEBOX 
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xor ax, ax ; return 0 
pop bp 
retn OAh 

WinMain endp 


t ne va pas étre utilisée, mais le compilateur a généré le code qui stocke la valeur. 


Car il n'est pas sûr, peut-être que la valeur sera utilisée dans un autre module. 


Chapitre 4 


Java 


4.1 Java 


4.1.1 Introduction 


Il existe des décompilateurs trés connus pour Java (ou pour du bytecode JVM en 
général) !. 


La raison est que la décompilation du bytecode JVM est un peu plus facile que du 
code x86 de plus bas niveau: 


* Il y a bien plus d'informations sur les types de données. 
* Le modéle de la mémoire JVM est beaucoup plus rigoureux et décrit. 


* Le compilateur Java ne fait pas d'optimisation (JVM JIT? le fait à l'exécution), 
donc le bytecode dans les fichiers de classe est généralement assez lisible. 


Quand est-ce que la connaissance de la JVM est utile? 


Créer des patchs "Quick-and-dirty" des fichiers de classe sans avoir besoin de 
recompiler les résultats du décompilateur. 


Analyse de code obfusqué. 


Analyser du code généré par les nouveaux compilateurs Java, pour lesquels il 
n'existe pas encore de décompilateur mis à jour. 


Construire votre propre obfuscateur. 


Construire un compilateur générateur de code (back-end) ciblant la JVM (comme 
Scala, Clojure, etc. ?). 


Commengons avec quelques bouts de code. Le JDK 1.7 est ici utilisé partout, sauf 
mention contraire. 


lPar exemple, JAD: http: //varaneckas .com/jad/ 
2Just-In-Time compilation 
3Liste compléte: http://en.wikipedia.org/wiki/List of JVM languages 
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Voici la commande utilisée partout pour décompiler les fichiers de classe : 
javap -c -verbose. 


Voici le livre que j'ai utilisé pour préparer tous les exemples : [Tim Lindholm, Frank 
Yellin, Gilad Bracha, Alex Buckley, The Java(R) Virtual Machine Specification / Java 
SE 7 Edition] ^. 


4.1.2 Renvoyer une valeur 


La fonction Java la plus simple est probablement celle qui renvoie une valeur. 


Il faut garder en téte qu'il n'y a pas de fonction «libre» en Java au sens commun, ce 
sont des «méthodes ». 


Chaque méthode est liée à une classe, donc il n'est pas possible de définir une 
méthode en dehors d'une classe. 


Mais nous allons quand méme les appeler des «fonctions », par simplicité. 


public class ret 


1 
public static int main(String[] args) 
1 
return 0; 
} 
} 


Compilons le : 


javac ret.java 


...et décompilons le en utilisant l'outil Java standard : 


javap -c -verbose ret.class 


Nous obtenons : 


Listing 4.1 : JDK 1.7 (extrait) 


public static int main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-1, locals-1, args size-1 
0: iconst 0 
1: ireturn 


Les développeurs Java ont décidé que comme 0 est l'une des constantes les plus 
utilisées en programmation, alors il existe une courte instruction séparée d'un octet, 
iconst 0 qui pousse O ?. 


Il y a aussi iconst 1 (qui pousse 1), iconst 2, etc., jusqu'à iconst 5. 


^Aussi disponible en https: //docs.oracle.com/javase/specs/jvms/se7/jvms7 .pdf ; http://docs. 
oracle.com/javase/specs/jvms/se7/html/ 
5Comme en MIPS où un registre séparé existe pour la constante zéro : 1.5.4 on page 36. 
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Il existe également l'instruction iconst m1 qui pousse -1. 


La pile est utilisée en JVM pour passer des données à une fonction appelée et éga- 
lement pour renvoyer des valeurs. Donc iconst 0 pousse O sur la pile. ireturn 
renvoie une valeur entière (i dans le nom signifie integer) depuis le TOS$. 


Réécrivons légérement notre exemple, pour qu'il renvoie 1234 maintenant : 


public class ret 


1 
public static int main(String[] args) 
{ 
return 1234; 
} 
} 
...DOUS avons : 


Listing 4.2 : JDK 1.7 (extrait) 


public static int main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=1, locals-1, args size-1 
0: sipush 1234 
3: ireturn 


sipush (short integer) pousse 1234 sur la pile. short dans le nom implique qu'une 
valeur de 16-bit va étre poussée. Le nombre 1234 tiens bien, en effet, dans une 
valeur de 16-bit. 


Qu'en est-il des valeurs plus grandes? 


public class ret 


{ 

public static int main(String[] args) 

{ 

return 12345678; 

} 

} 
Listing 4.3 : Constant pool 
#2 = Integer 12345678 


public static int main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: ldc $2 // int 12345678 
2: ¡return 


6Top of Stack 
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Ce n'est pas possible d'encoder un nombre 32-bit dans une instruction opcode JVM, 
les développeurs n'ont pas laissé une telle possibilité. 


Donc le nombre 32-bit 12345678 est enregistré dans ce qu'on appelle le «constant 
pool» qui est, disons, la bibliothèque des constantes les plus utilisées (incluant les 
strings, objects, etc.). 


Cette facon de passer des constantes n'est pas propre à JVM. 


MIPS, ARM et les autres CPUs RISC ne peuvent pas non plus encoder un nombre 
32-bit dans un opcode de 32-bit, donc le code CPU RISC (incluant MIPS et ARM) doit 
construire la valeur en plusieurs étapes, ou le garder dans le segment des données : 
1.39.3 on page 570, 1.40.1 on page 574. 


Le code MIPS a aussi traditionnellement un pool des constantes, nommé «literal 
pool», les segments sont nommés «.lit4 » (pour des nombres flottants constants de 
simples précisions sur 32-bit) et «.lit8» (pour des nombres flottants constants de 
double précision sur 64-bit). 


Essayons quelques autres types de données! 


Boolean: 
public class ret 
1 
public static boolean main(String[] args) 
1 
return true; 
} 
} 


public static boolean main(java.lang.String[]); 
flags: ACC PUBLIC, ACC_STATIC 
Code: 
stack=1, locals-1, args size-1 
0: iconst 1 
1: ireturn 


Ce bytecode JVM n'est pas différent de celui qui retourne l'entier 1. 


Les emplacements de données 32-bits dans la pile sont aussi utilisés ici pour des 
valeurs booléennes, comme en C/C++. 


Mais on ne peut pas utiliser la valeur booléenne retournée comme un entier ou vice 
versa - l'information du type est enregistrée dans le fichier de classe et et vérifiée 
à l'exécution. 


C'est la méme histoire qu'un short 16-bit : 


public class ret 


1 
public static short main(String[] args) 
{ 
return 1234; 
} 
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public static short main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: sipush 1234 
3: ireturn 
...et char! 
public class ret 
{ 
public static char main(String[] args) 
{ 
return 'A'; 
} 
} 


public static char main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: bipush 65 
2: ireturn 


bipush signifie «push byte ». Inutile de préciser qu'un char en Java est un caractére 
UTF-16 16-bit, ce qui équivaut à un short, mais le code ASCII du caractère «A» est 
65, et c'est possible d'utiliser cette instruction pour pousser un octet dans la pile. 


Essayons aussi un byte : 


public class retc 


1 
public static byte main(String[] args) 
1 
return 123; 
} 
} 


public static byte main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: bipush 123 
2: ireturn 


On peut se demander, pourquoi s'embéter avec avec un type de donnée short de 
16-bit qui fonctionne en interne comme un entier 32-bit? 


Pourquoi utiliser un type de donnée char si c'est pareil qu'un type de donnée short? 


La réponse est simple : pour le contróle du type de données et pour la lisibilité du 
code source. 
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Un char peut étre essentiellement le méme qu'un short, mais nous saisissons rapi- 
dement que c'est un substitut pour un caractére 16-bit, et non pour une autre valeur 
entiére. 


Quand on utilise short, nous montrons à tout le monde que la plage de la variable 
est limitée à 16 bits. 


C'est une trés bonne idée d'utiliser le type boolean ou c'est nécessaire, plutót que 
le int de style C. 


Il y a aussi un type de donnée entier sur 64-bits en Java : 


public class ret3 


1 

public static long main(String[] args) 

{ 

return 1234567890123456789L; 

} 

} 
Listing 4.4 : Constant pool 
#2 = Long 12345678901234567891 


public static long main (java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-1, args size-1 
0: ldc2 w #2 // long 12345678901234567891 
3: lreturn 


Le nombre 64-bit est aussi stocké dans le pool des constantes, ldc2 w le charge et 
lreturn (long return) le retourne. 


L'instruction ldc2 w est aussi utilisée pour charger des nombres flottants double 
précision (qui occupent aussi 64 bits) depuis le pool des constantes : 


public class ret 


1 
public static double main(String[] args) 
1 
return 123.456d; 
} 
} 


Listing 4.5 : Constant pool 


$2 = Double 123. 456d 
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public static double main (java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-1, args size-1 
0: ldc2 w #2 // double 123.456d 
3: dreturn 


dreturn signifie «return double ». 
Et enfin, un nombre flottant simple précision : 


public class ret 


{ 

public static float main(String[] args) 

{ 

return 123.456f; 

} 

} 
Listing 4.6 : Constant pool 
#2 = Float 123.456f 


public static float main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=1, locals-1, args size-1 
0: ldc #2 // float 123.456f 
2: freturn 


L'instruction ldc utilisée ici est la méme que celle pour charger des nombres entiers 
de 32-bit depuis le pool des constantes. 


freturn signifie «return float ». 


Maintenant, qu'en est-il de la fonction qui ne retourne rien? 


public class ret 


1 
public static void main(String[] args) 
1 
return; 
} 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=0, locals-1, args size-1 
0: return 
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Cela signifie que l'instruction return est utilisée pour retourner le contróle sans 
renvoyer une vraie valeur. 


En sachant cela, il est trés facile de déduire le type renvoyé par des fonctions (ou 
des méthodes) depuis la derniére instruction. 


4.1.3 Fonctions de calculs simples 


Continuons avec une fonction de calcul simple. 


public class calc 


1 
public static int half(int a) 
1 
return a/2; 
} 
} 


Voici la sortie quand l'instruction iconst 2 est utilisée : 


public static int half(int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-1, args size-1 

0: iload 0 
1: iconst 2 
2: idiv 
3: ireturn 


iload 0 prend le zéroième argument de la fonction et le pousse sur la pile. 


iconst 2 pousse 2 sur la pile. Aprés l'exécution de ces deux instructions, voici à 
quoi ressemble la pile : 


+---+ 
TOS ->| 2 | 
+---+ 
| a | 
+---+ 


idiv prend juste les deux valeurs depuis le TOS, divise l'un par l'autre et laisse le 
résultat au TOS : 


ireturn le prend et le renvoie. 


Procédons avec un nombre flottant double précision : 


public class calc 


{ 
public static double half double(double a) 
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1 
return a/2.0; 
} 
} 
Listing 4.7 : Constant pool 
#2 = Double 2.0d 


public static double half double(double); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-4, locals-2, args size-1 
0: dload 0 
1: ldc2 w #2 // double 2.0d 
4: ddiv 
5: dreturn 


C'est pareil, mais l'instruction ldc2 w est utilisée pour charger la constante 2.0 de- 
puis le pool des constantes. 


Aussi, les trois autres instructions sont préfixées par d, ce qui signifie qu'elles tra- 
vaillent avec des valeurs de type double. 


Utilisons maintenant une fonction avec deux arguments : 


public class calc 


1 
public static int sum(int a, int b) 
1 
return atb; 
} 
} 


public static int sum(int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-2, args size-2 
0: iload 0 
1: iload 1 
2: iadd 
3: ireturn 


iload 0 charge le premier argument de la fonction (a), iload 1—le second (b). 


Voici la pile aprés l'exécution de ces instructions : 


+---+ 
TOS ->| b | 
+---+ 
| a | 
+---+ 
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iadd ajoute les deux valeurs et laisse le résultat au TOS : 


Étendons cet exemple avec le type /ong : 


public static long lsum(long a, long b) 
{ 


} 


return atb; 


.. NOUS avons : 


public static long lsum(long, long); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-4, locals-4, args size-2 
0: lload 0 
1: lload 2 
2: ladd 
3: lreturn 


La deuxième instruction Lload prend le second argument depuis la 2ème position. 


C'est parce que la valeur d'un /ong de 64-bit occupe exactement deux places de 
32-bit. 


Exemple un peu plus avancé : 


public class calc 


1 
public static int mult add(int a, int b, int c) 
1 
return a*b+c; 
} 
} 


public static int mult add(int, int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-3, args size-3 
: iload 0 
iload 1 
imul 
iload 2 
iadd 
ireturn 
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La premiére étape est la multiplication. Le produit est laissé au TOS : 
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iload_2 charge le troisieme argument (c) dans la pile: 


+--------- + 
TOS ->| C | 
+--------- + 
| produit | 
+--------- + 


Maintenant l'instruction iadd peut ajouter les deux valeurs. 


4.1.4 Modèle de mémoire de la JVM 


x86 et d'autres environnements de bas niveau utilisent la pile pour le passage des 
paramétres et le stockage de variables locales. 


La JVM est légérement différente. 
Elle a: 


* Letableau des variables locales, Local Variable Array (LVA?). Il est utilisé comme 
stockage pour les paramétres en entrée de fonction et les variables locales. 


Des instructions comme iload 0 charge une valeur depuis cet espace. 


istore y stocke des valeurs. Au début les paramétres de la fonction sont sto- 
ckés: commengant a 0 ou à 1 (si l'indice O est occupé par le pointeur this). 


Ensuite les variables locales sont allouées. 
Chaque slot a une taille de 32-bit. 


De ce fait, les valeurs de types de données /ong et double occupent deux slots. 


Pile des opérandes (ou simplement «pile »). Elle est utilisée pour les calculs et 
la passage de paramétres lors de l'appel d'autres fonctions. 


Contrairement aux environnements bas niveau comme x86, il n'est pas possible 
d'accéder à la pile sans utiliser des instructions qui poussent ou prennent des 
valeurs dans/depuis la pile. 


* Heap. Il est utilisé pour le stockage d'objets et de tableaux. 
Ces 3 espaces sont isolés les uns des autres. 


4.1.5 Appel de fonction simple 


Math.random() renvoie un nombre pseudo-aléatoire dans l'intervalle [0.0 ...1.0], 
mais disons que une certaine raison, nous devons concevoir une fonction qui ren- 
voie un nombre dans l'intervalle [0.0 ...0.5] : 


public class HalfRandom 


1 
public static double f() 


{ 


7(Java) Local Variable Array 
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return Math.random()/2; 


} 
} 
Listing 4.8 : Constant pool 
#2 = Methodref #18.#19 // java/lang/Math. random: ()D 
#3 = Double 2.0d 
#12 = Utf8 ()D 
#18 = Class #22 // java/lang/Math 
#19 = NameAndType #23:#12 // random: ()D 
#22 = Utf8 java/lang/Math 
#23 = Utf8 random 


public static double f(); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-4, locals=0, args size-0 
0: invokestatic #2 // Method java/lang/Math. random: ()D 
3: ldc2 w #3 // double 2.0d 
6: ddiv 
7: dreturn 


invokestatic appelle la fonction Math. random() et laisse le résultat sur le TOS. 
Le résultat est divisé par 2.0 et renvoyé. 

Mais comment est encodé le nom de la fonction? 

Il est encodé dans le pool constant en utilisant une expression Methodref. 

Il définit les noms de classe et méthode. 


Le premier champ de Methodref pointe sur une expression Class qui, a son tour, 
pointe sur la chaine de texte usuel («java/lang/Math »). 


La seconde expression de Methodref pointe sur une expression NameAndType qui a 
aussi deux liens sur des chaines. 


La premiére chaine est «random », qui est le nom de la méthode. 


La seconde chaine est «()D », qui encode le type de la fonction. Cela signifie qu’elle 
renvoie une valeur double (d'oü le D dans la chaíne). 


Ceci est la facon dont 1) la JVM peut vérifier la justesse des types de données; 2) 
les décompilateurs Java peuvent retrouver les types de données depuis un fichier 
de classe compilée. 


Maintenant, essayons l'exemple «Hello, world! » : 


public class HelloWorld 
{ 
public static void main(String[] args) 
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1 
System.out.println("Hello, World"); 
} 
} 
Listing 4.9 : Constant pool 
#2 = Fieldref #16.#17 // java/lang/System.out:Ljava/io7 
y /PrintStream; 
#3 = String #18 // Hello, World 
#4 = Methodref #19.#20 // java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 

#16 = Class #23 // java/lang/System 

#17 = NameAndType #24:#25 // out:Ljava/io/PrintStream; 
#18 = Utf8 Hello, World 
#19 = Class #26 // java/io/PrintStream 
320 = NameAndType #27:#28 // println:(Ljava/lang/String;)V 
#23 = Utf8 java/lang/System 
424 = Utf8 out 
#25 = Utf8 Ljava/io/PrintStream; 
#26 = Utf8 java/io/PrintStream 
#27 = Utf8 println 
#28 = Utf8 (Ljava/lang/String;)V 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-1, args size-1 

0: getstatic #2 // Field java/lang/System.out:Ljava/io/7 
S PrintStream; 

3: ldc 33 // String Hello, World 

5: invokevirtual £4 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 

8: return 


ldc a l'offset 3 prend un pointeur sur la chaîne «Hello, World » dans le pool constant 
et le pousse sur la pile. 


C'est appelé une référence dans le monde Java, mais c'est plutót un pointeur, ou 
une adresse?. 


L'instruction connue invokevirtual prend les informations concernant la fonction 
println (ou méthode) depuis le pool constant et l'appelle. 


Comme on peut le savoir, il y a plusieurs méthodes println, une pour chaque type 
de données. 


Dans notre cas, c'est la version de println destinée au type de données String. 


8À propos de la différence entre pointeurs et références en C++ voir: 3.21.3 on page 721. 
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Mais qu'en est-il de la première instruction getstatic ? 


Cette instruction prend une référence (ou l'adresse de) un champ de l’objet System. out 
et le pousse sur la pile. 


Cette valeur se comporte comme le pointeur this pour la méthode println. 


Ainsi, en interne, la méthode println prend deux paramétres en entrée: 1)this, i.e., 
un pointeur sur un objet; 2) l'adresse de la chaîne «Hello, World ». 


En effet, println() est appelé comme une méthode dans un objet System.out ini- 
tialisé. 
Par commodité, l'utilitaire javap écrit toutes ces informations dans les commen- 
taires. 


4.1.6 Appel de beep() 


Ceci est un simple appel de deux fonctions sans paramétre: 


public static void main(String[] args) 


1 
un 


java.awt.Toolkit.getDefaultToolkit().beep(); 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=1, locals-1, args size-1 

0: invokestatic 72 // Method java/awt/Toolkit. ? 

y getDefaultToolkit: ()Ljava/awt/Toolkit; 
3: invokevirtual £3 // Method java/awt/Toolkit.beep:()V 
6: return 


Le premier invokestatic à l'offset O appelle 
java.awt.Toolkit.getDefaultToolkit(), qui renvoie une référence sur un objet 
de la classe Toolkit. 

L'instruction invokevirtual à l'offset 3 appelle la méthode beep() de cette classe. 


4.1.7 Congruentiel linéaire PRNG 


Essayons un simple générateur de nombres pseudo-aléatoires, que nous avons déjà 
considéré une fois dans ce livre (1.29 on page 436) : 


public class LCG 
1 


public static int rand state; 


public void my srand (int init) 


{ 
} 


rand_state=init; 
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public static int RNG_a=1664525; 
public static int RNG_c=1013904223; 


public int my_rand () 


1 
rand state-rand state*RNG a; 
rand state-rand state+RNG c; 
return rand state € Ox7fff; 
} 


Il y a un couple de champs de classe qui sont initialisés au début. 


Mais comment? Dans la sortie de javap, nous pouvons trouver le constructeur de la 
classe: 


static {}; 
flags: ACC STATIC 
Code: 
stack=1, locals=0, args size-0 

0: ldc #5 // int 1664525 
2: putstatic #3 // Field RNG a:I 
5: ldc #6 // int 1013904223 
7: putstatic #4 // Field RNG c:I 
10: return 


C’est ainsi que les variables sont initialisées. 


RNG a occupe le 3ème slot dans la classe et RNG c—le 4ème, et putstatic met les 
constantes ici. 


La fonction my srand() stocke simplement la valeur en entrée dans rand state: 


public void my srand(int); 
flags: ACC PUBLIC 


Code: 
stack=1, locals-2, args size-2 
0: iload 1 
1: putstatic #2 // Field rand state:I 
4: return 


iload 1 prend la valeur en entrée et la pousse sur la pile. Mais pourquoi pasiload 0? 


C'est parce que cette fonction peut utiliser les champs de la classe, et donc this est 
aussi passé à la fonction comme paramétre d'indice zéro. 


Le champ rand state occupe le 2éme slot dans la classe, donc putstatic copie la 
valeur depuis le TOS dans le 2éme slot. 


Maintenant my rand() : 


public int my rand(); 
flags: ACC PUBLIC 
Code: 
stack-2, locals-1, args size-1 
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0: getstatic #2 // Field rand state:I 
3: getstatic #3 // Field RNG a:I 

6: imul 

7: putstatic #2 // Field rand state:I 
10: getstatic #2 // Field rand state:I 
13: getstatic #4 // Field RNG c:I 

16: iadd 

17: putstatic #2 // Field rand state:I 
20: getstatic #2 // Field rand state:I 
23: sipush 32767 

26: iand 


27: ireturn 


Ca charge toutes les valeurs depuis les champs de l'objet, effectue l'opération et 
met à jour les valeurs de rand state en utilisant l'instruction putstatic. 


À l'offset 20, rand state est rechargé à nouveau (car il a été supprimé de la pile 
avant, par putstatic). 


Ceci semble non-efficient, mais soyez assuré que la JVM est en général assez bonne 
pour vraiment bien optimiser de telles choses. 


4.1.8 Conditional jumps 


Maintenant, continuons avec les sauts conditionnels. 


public class abs 


{ 
public static int abs(int a) 
{ 
if (a<0) 
return -a; 
return a; 
} 
} 


public static int abs(int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=1, locals-1, args size-1 
: iload 0 
ifge 7 
iload 0 
ineg 
ireturn 
iload 0 
ireturn 
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ifge saute à l'offset 7 si la valeur du TOS est plus grande ou égale à 0. 


N'oubliez pas que chaque instruction ifXX supprime la valeur (qui doit étre compa- 
rée) de la pile. 
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ineg inverse le signe de la valeur du TOS. 


Un autre exemple: 


public static int min (int a, int b) 
1 
if (a»b) 
return b; 
return a; 


Nous obtenons: 


public static int min(int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-2, args size-2 
: iload 0 
iload 1 
if icmple 7 
iload 1 
ireturn 
iload 0 
ireturn 
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if icmple prend deux valeurs et les compare. Si la seconde est plus petite ou égale 
à la premiére, un saut à l'offset 7 est effectué. 


Quand nous définissons la fonction max() ... 


public static int max (int a, int b) 
1 
if (a»b) 
return a; 
return b; 


le code résultant est le méme, mais les deux dernières instructions iload (aux 
offsets 5 et 7) sont échangées: 


public static int max(int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-2, args size-2 
: iload 0 
iload 1 
if icmple 7 
iload 0 
ireturn 
iload 1 
ireturn 
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Un exemple plus avancé: 
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public class cond 


t 
public static void f(int i) 
1 
if (i«100) 
System.out.print("«100"); 
if (i--100) 
System.out.print("--100"); 
if (i>100) 
System.out.print(">100"); 
if (i==0) 
System.out.print("==0"); 
} 
} 


public static void f(int); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-1, args size-1 

0: iload 0 

1: bipush 100 

3: if_icmpge 14 

6: getstatic #2 // Field java/lang/System.out:Ljava/io// 
y PrintStream; 

9: ldc #3 // String <100 

11: invokevirtual #4 // Method java/io/PrintStream.print: (7 
y Ljava/lang/String;)V 

14: iload_0 

15: bipush 100 

17: if_icmpne 28 

20: getstatic #2 // Field java/lang/System.out:Ljava/io/2 
& PrintStream; 

23: ldc #5 // String ==100 

25: invokevirtual #4 // Method java/io/PrintStream.print: (7 
y Ljava/lang/String;)V 

28: iload_0 

29: bipush 100 

31: if icmple 42 

34: getstatic #2 // Field java/lang/System.out:Ljava/io// 
S PrintStream; 

37: ldc #6 // String >100 

39: invokevirtual #4 // Method java/io/PrintStream.print: (7 
y Ljava/lang/String;)V 

42: iload_0 

43: ifne 54 

46: getstatic #2 // Field java/lang/System.out:Ljava/io// 
& PrintStream; 

49: ldc 37 // String == 

51: invokevirtual +4 // Method java/io/PrintStream.print: (7 


y Ljava/lang/String;)V 
54: return 
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if icmpge prend deux valeurs et les compare. Si le seconde est plus grande que la 
premiére, un saut à l'offset 14 est effectué. 


if icmpne et if icmple fonctionnent de la méme facon, mais implémentent des 
conditions différentes. 


Il y a aussi une instruction ifne à l'offset 43. 


Le nom est un terme inapproprié, il aurait été meilleur de l'appeler ifnz (saut si la 
valeur du TOS n'est pas zéro). 


Et c'est ce qu'elle fait: elle saute à l'offset 54 si la valeur en entrée n'est pas zéro. 


Si c'est zéro, le flux d'exécution continue à l'offset 46, où la chaîne «2-0 » est affi- 
chée. 


N.B.: la JVM n'a pas de type de données non signée, donc les instructions de compa- 
raison opérent seulement sur des valeurs entiéres signées. 


4.1.9 Passer des paramétres 


Étendons notre exemple de min()/max() : 


public class minmax 


1 
public static int min (int a, int b) 
1 
if (a»b) 
return b; 
return a; 
} 
public static int max (int a, int b) 
{ 
if (a>b) 
return a; 
return b; 
} 
public static void main(String[] args) 
{ 
int a=123, b=456; 
int max_value=max(a, b); 
int min_value=min(a, b); 
System.out.println(min value); 
System.out.println(max value); 
} 
} 


Voici le code de la fonction main() : 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC_STATIC 
Code: 
stack=2, locals=5, args size-1 
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0: bipush 123 
2: istore 1 
3: sipush 456 
6: istore 2 
7: iload 1 
8: iload 2 
9: invokestatic #2 // Method max: (II)I 
12: istore 3 
13: iload 1 
14: iload 2 
15: invokestatic #3 // Method min: (11)1 
18: istore 4 
20: getstatic 34 // Field java/lang/System.out:Ljava/io/^7 
y PrintStream; 
23: iload 4 
25: invokevirtual #5 // Method java/io/PrintStream.println: (1, 
S JV 
28: getstatic 34 // Field java/lang/System.out:Ljava/io/ Y 
y PrintStream; 
31: iload 3 
32: invokevirtual #5 // Method java/io/PrintStream.println: (12 
& JV 
35: return 


Les paramètres sont passés à l’autre fonction dans la pile, et la valeur renvoyée est 
laissée sur le TOS. 


4.1.10 Champs de bit 


Toutes les opérations au niveau des bits fonctionnent comme sur les autres ISA : 


public static int set (int a, int b) 


{ 
return a | 1<<b; 
} 
public static int clear (int a, int b) 
{ 
return a € (-(1««b)); 
} 


public static int set(int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack=3, locals-2, args size-2 

: iload 0 

iconst 1 

iload 1 

ishl 

ior 

ireturn 
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public static int clear(int, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack=3, locals-2, args size-2 

: iload 0 

iconst 1 

iload 1 

ishl 

iconst ml 

ixor 

iand 

ireturn 
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iconst ml charge -1 sur la pile, c'est la méme chose que le nombre OxFFFFFFFF. 
XORé avec OxFFFFFFFF a le méme effet qu'inverser tous les bits. 
Étendons tous les types de données à 64-bit /ong : 


public static long lset (long a, int b) 


i 
return a | 1<<b; 
} 
public static long lclear (long a, int b) 
{ 
return a € (-(1««b)); 
} 


public static long lset(long, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack-4, locals-3, args size-2 

: lload 0 

iconst 1 

iload 2 

ishl 

i2l 

lor 

lreturn 
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public static long lclear(long, int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack-4, locals-3, args size-2 

: lload_0 

iconst 1 

iload 2 

ishl 

iconst ml 

ixor 

i2l 

land 

lreturn 


© Y OY Ul .» UJ) NJ H © 


876 


Le code est le méme, mais des instructions avec le préfixe / sont utilisées, qui opérent 
avec des valeurs 64-bit. 


Ainsi, le second paramétre de la fonction est toujours du type int, et lorsque la va- 
leur 32-bit qu'il contient doit être étendues à une valeur 64-bit, l'instruction i21 est 
utilisée, 


4.1.11 Boucles 


public class Loop 


{ 
public static void main(String[] args) 
{ 
for (int i = 1; i <= 10; i++) 
{ 
System. out.printtn(i) ; 
} 
} 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-2, args size-1 

0: iconst 1 

1: istore 1 

2: iload 1 

3: bipush 10 

5: if icmpgt 21 

8: getstatic #2 // Field java/lang/System.out:Ljava/iov 
y /PrintStream; 

11: iload_1 

12: invokevirtual #3 // Method java/io/PrintStream.println” 
S :(I)V 

15: iinc 1, 1 

18: goto 2 

21: return 


iconst_1 loads 1 into TOS, istore 1 stores it in the LVA at slot 1. 


Pourquoi pas le slot d'indice zéro? Car la fonction main() a un paramétre (tableau 
de String) et un pointeur sur ce dernier (ou une référence) qui est maintenant dans 
le slot O. 


Donc, la variable locale į sera toujours dans le premier slot. 

Les instructions aux offsets 3 et 5 comparent / avec 10. 

Si i est plus grand, le flux d'exécution passe à l'offset 21, où la fonction se termine. 
Si non, println est appelée. 


i est ensuite rechargé à l'offset 11, pour println. 
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A propos, nous appelons la méthode println pour un entier, et nous voyons this 
dans le commentaire: «(I)V » ((/ signifie integer et V signifie que le type de retour 
est void). 


Lorsque println termine, i est incrémenté à l'offset 15. 


Le premier opérande de l'instruction est le numéro d'un slot (1), le second est le 
nombre a ajouté à la variable. 


Procédons avec un exemple plus complexe: 


public class Fibonacci 


1 
public static void main(String[] args) 
1 
int limit = 20, f = 0, g= 1; 
for (int i = 1; i <= limit; i++) 
{ 
f=f+09; 
g=f-g; 
System.out.println(f); 
} 
} 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals=5, args size-1 
: bipush 20 
istore 1 
iconst 0 
istore 2 
iconst 1 
istore 3 
iconst 1 
istore 4 
: iload 4 
: iload 1 
: if icmpgt 37 
: iload 2 
: iload 3 
: iadd 
: istore 2 
: iload 2 
21: iload 3 
22: isub 
23: istore 3 
24: getstatic #2 // Field java/lang/System.out:Ljava/iov 
y /PrintStream; 
27: iload 2 
28: invokevirtual #3 // Method java/io/PrintStream.println” 
S :(I)V 
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31: iinc 4, 1 
34: goto 10 
37: return 


Voici une carte des slots LVA : 
* 0 — le seul paramétre de main() 
* 1 — limit, contient toujours 20 


Te. 
. 3—9 
-4—i 


Nous voyons que le compilateur Java alloue les variables dans des slots LVA dans le 
méme ordre qu'elles sont déclarées dans le code source. 


Il y a des instructions istore séparées pour accéder aux slots 0, 1, 2 et 3, mais pas 
pour 4 et plus, donc il y a un istore avec un paramétre supplémentaire à l'offset 8 
qui prend le numéro du slot comme opérande. 


Il y a la méme chose avec iload à l'offset 10. 


Mais n'est-il pas douteux d'allouer un autre slot pour la variable /imit, qui contient 
toujours 20 (donc c'est par essence une constante), et de recharger sa valeur si 
souvent? 


Le compilateur JIT de la JVM est en général assez bon pour optimiser de telles choses. 


Une intervention manuelle dans le code n'en vaut probablement pas la peine. 


4.1.12 switch() 


La déclaration switch() est implémentée avec l'instruction tableswitch : 


public static void f(int a) 


1 
switch (a) 
1 
case 0: System.out.println("zero"); break; 
case 1: System.out.println("one\n"); break; 
case 2: System.out.println("two\n"); break; 
case 3: System.out.println("three\n"); break; 
case 4: System.out.println("four\n"); break; 
default: System.out.println("something unknown\n"); break; 
h 

} 


Aussi simple que possible: 


public static void f(int); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-1, args size-1 
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0: iload 0 
1: tableswitch 


0: 
1: 
2: 
3: 
4: 
t: 


defaul 
} 
36: getstatic 
& PrintStream; 
39: ldc 
41: invokevirtual 
y Ljava/lang/String;)V 
44: goto 
47: getstatic 
& PrintStream; 
50: ldc 
52: invokevirtual 
S Ljava/lang/String;)V 
55: goto 
58: getstatic 
& PrintStream; 
61: ldc 
63: invokevirtual 
y Ljava/lang/String;)V 
66: goto 
69: getstatic 
& PrintStream; 
72: ldc 
74: invokevirtual 
y Ljava/lang/String;)V 
77: goto 
80: getstatic 
& PrintStream; 
83: ldc 
85: invokevirtual 
y Ljava/lang/String;)V 
88: goto 
91: getstatic 
& PrintStream; 
94: ldc 
96: invokevirtual 
y Ljava/lang/String;)V 
99: return 


( // 0 to 
36 
47 
58 
69 
80 
91 
#2 // 
#3 // 
#4 // 
99 
#2 // 
#5 // 
#4 // 
99 
#2 // 
#6 // 
#4 // 
99 
#2 // 
#7 // 
#4 // 
99 
#2 // 
#8 // 
#4 // 
99 
#2 // 
#9 // 
#4 // 


Field java/lang/System. out: 


String zero 


Method java/io/PrintStream. 


Field java/lang/System. out: 


String one\n 


Method java/io/PrintStream. 


Field java/lang/System. out: 


String two\n 


Method java/io/PrintStream. 


Field java/lang/System. out: 


String three\n 


Method java/io/PrintStream. 


Field java/lang/System. out: 


String four\n 


Method java/io/PrintStream. 


Field java/lang/System. out: 


String something unknown\n 


Method java/io/PrintStream. 


Ljava/io/ 2 


printin: (2 


Ljava/io/ 2 


printin: (2 


Ljava/io/ 2 


printlin: (2 


Ljava/io/ z2 


printin: (2 


Ljava/io/ z 


printin: (2 


Ljava/io/ z2 


printin: (2 


4.1.13 Tableaux 


Exemple simple 


Créons d'abord un tableau de 10 entiers et remplissons le: 


public static void main(String[] args) 
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1 
int a[]=new int[10]; 
for (int i20; i<10; i++) 
alil=i; 
dump (a); 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=3, locals-3, args size-1 
0: bipush 10 
2: newarray int 
4: astore 1 
5: iconst 0 
6: istore 2 
7: iload 2 
8: bipush 10 
10: if icmpge 23 
13: aload 1 
14: iload 2 
15: iload 2 
16: iastore 
17: iinc 2, 1 
20: goto 7 
23: aload 1 
24: invokestatic #4 // Method dump: ([I)V 
27: return 


L'instruction newarray créée un objet tableau de 10 éléments de type int. 
La taille du tableau est définie par bipush et laissée sur le TOS. 
Le type du tableau est mis dans l'opérande de l'instruction newarray. 


Aprés l'exécution de newarray, une référence (ou pointeur) sur le tableau nouvelle- 
ment créé dans le heap est laissée sur le TOS. 


astore 1 stocke la référence dans le ler slot dans LVA. 


La seconde partie de la fonction main() est la boucle qui stocke i dans l'élément du 
tableau correspondant. 


aload 1 obtient une référence du tableau et la met sur la pile. 


iastore stocke ensuite la valeur entiére de la pile dans le tableau, dont la référence 
se trouve dans TOS. 


La troisième partie de la fonction main() appelle la fonction dump). 
Un argument lui est préparé par aload 1 (offset 23). 


Maintenant regardons la fonction dump() : 


public static void dump(int a[]) 


1 
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for (int i20; i«a.length; i++) 
System.out.println(a[i]); 
} 
public static void dump(int[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=3, locals-2, args size-1 

0: iconst 0 

1: istore 1 

2: iload 1 

3: aload 0 

4: arraylength 

5: if icmpge 23 

8: getstatic #2 // Field java/lang/System.out:Ljava/io/ z2 
s PrintStream; 

11: aload 0 

12: iload 1 

13: iaload 

14: invokevirtual £3 // Method java/io/PrintStream.println: (1), 
GV 

17: iinc 1, 1 

20: goto 2 

23: return 


La référence entrante sur le tableau est dans le slot d'indice 0. 


L'expression a. length dans le code source est convertie en une instruction arraylength : 
elle prend une référence sur le tableau et laisse sa taille sur le TOS. 


iaload à l'offset 13 est utilisée pour charger des éléments du tableau, elle nécessite 
qu'une référence sur le tableau soit présente dans la pile (préparée par aload 0 en 
11), et aussi un index (préparé par iload 1 a l'offset 12). 


Inutile de dire que les instructions préfixées par a peuvent étre, par erreur, mal 
interprétées comme des instructions d'array (tableaux). 


C'est incorrect. Ces instructions travaillent avec des références sur les objets. 


Et les tableaux et les chaines sont aussi des objets. 


Sommer les éléments d'un tableau 


Un autre exemple: 


public class ArraySum 
1 
public static int f (int[] a) 
1 
int sum-0; 
for (int i20; i«a.length; i++) 
sum-sum-a [i]; 
return sum; 
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public static int f(int[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack=3, locals-3, args size-1 
0: iconst 0 
1: istore 1 
2: iconst 0 
3: istore 2 
4: iload 2 
5: aload 0 
6: arraylength 
7: if icmpge 22 
10: iload 1 
11: aload 0 
12: iload 2 
13: iaload 
14: iadd 
15: istore 1 
16: iinc 
19: goto 4 
22: iload 1 
23: ireturn 


N 
m. 


Le slot O du LVA contient une référence sur le tableau en entrée. 


Le slot 1 du LVA contient la variable locale sum. 


Le seul argument de la fonction main() est aussi un tableau 


Nous allons utiliser le seul argument de la fonction main(), qui est un tableau de 
chaînes: 


public class UseArgument 


{ 
public static void main(String[] args) 
{ 
System.out.print("Hi, "); 
System.out.print(args[1]); 
System.out.println(". How are you?"); 
} 
} 


L'argument d'indice zéro est le nom du programme (comme en C/C++, etc.), donc 
le ler argument fourni par l'utilisateur est à l'indice 1. 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=3, locals-1, args size-1 
0: getstatic #2 // Field java/lang/System.out:Ljava/io/ / 
y PrintStream; 
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3: ldc #3 

5: invokevirtual #4 
y Ljava/lang/String;)V 

8: getstatic 
& PrintStream; 

11: aload_0 

12: iconst_1 

13: aaload 

14: invokevirtual #4 
y Ljava/lang/String;)V 


// 
// 


#2 


17: getstatic #2 // 
V PrintStream; 

20: ldc #5 // 

22: invokevirtual #6 // 


y Ljava/lang/String;)V 
25: return 


String Hi, 
Method java/io/PrintStream.print: (7 


Field java/lang/System.out:Ljava/io/ 7 


Method java/io/PrintStream.print: (7 
Field java/lang/System.out:Ljava/io/2 


String . How are you? 
Method java/io/PrintStream.println: (2 


aload 0 en 11 charge une référence sur le slot zéro du LVA (ler et unique argument 


de main()). 


iconst 1 et aaload en 12 et 13 prend une référence sur l'élément 1 du tableau (en 


comptant depuis 0). 


La référence sur l'objet chaîne est sur le TOS à l'offset 14, et elle est prise d'ici par 


la méthode println 


Tableau de chaînes pré-initialisé 


class Month 


{ 


public static String[] months 


{ 
"January", 
"February", 
"March", 
"April", 
"May", 
"June", 
"July", 
"August", 
"September", 
"October", 
"November", 
"December" 

un 


public String get month (int 
1 


un 


return months[i]; 


i) 


La fonction get month() est simple: 
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public java.lang.String get month(int); 
flags: ACC PUBLIC 


Code: 
stack-2, locals-2, args size-2 
0: getstatic #2 // Field months: [Ljava/lang/String; 
3: iload 1 
4: aaload 
5: areturn 


aaload opére sur un tableau de références. 


Les String Java sont des objets, donc les instructions a sont utilisées pour opérer 
dessus. 


areturn renvoie une référence sur un objet String. 


Comment est initialisé le tableau months[] ? 


static {}; 

flags: ACC STATIC 

Code: 

stack-4, locals=0, args size-0 

: bipush 12 
anewarray #3 // class java/lang/String 
dup 
iconst_0 
ldc #4 // String January 
aastore 
: dup 
: iconst_1 
: ldc #5 // String February 
: aastore 
: dup 
: iconst 2 
: Ide #6 // String March 
: aastore 
: dup 
21: iconst_3 
22: ldc 37 // String April 
24: aastore 
25: dup 
26: iconst 4 
27: ldc +8 // String May 
29: aastore 
30: dup 
31: iconst_5 
32: ldc 39 // String June 
34: aastore 
35: dup 
36: bipush 6 
38: ldc 310 // String July 
40: aastore 
41: dup 
42: bipush 7 
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44: ldc #11 // String August 
46: aastore 

47: dup 

48: bipush 8 

50: ldc #12 // String September 
52: aastore 

53: dup 

54: bipush 9 

56: ldc #13 // String October 
58: aastore 

59: dup 

60: bipush 10 

62: ldc #14 // String November 
64: aastore 

65: dup 

66: bipush 11 

68: ldc #15 // String December 
70: aastore 

71: putstatic #2 // Field months: [Ljava/lang/String; 
74: return 


anewarray crée un nouveau tableau de références (d'oü le préfixe a). 


Le type de l'objet est défini dans l'opérande de anewarray, dans la chaine «java/- 
lang/String ». 


L'instruction bipush 12 avant anewarray défini la taille du tableau. 
Nous voyons une instruction nouvelle pour nous ici: dup. 


C'est une instruction standard dans les ordinateurs à pile (langage de programma- 
tion Forth inclus) qui duplique simplement la valeur du TOS. 


À propos, le FPU 80x87 est aussi un ordinateur à pile et posséde une instruction 
similaire - FDUP. 


Elle est utilisée ici pour dupliquer la référence sur un tableau, car l'instruction aastore 
supprime de la pile la référence sur le tableau, mais le aastore en aura à nouveau 
besoin. 


Le compilateur Java conclu qui est meilleur de générer un dup plutót que de générer 
une instruction getstatic avant chaque opération de stockage (i.e., 11 fois). 


aastore pousse une référence (sur la chaine) dans le tableau à un index qui est pris 
du TOS. 


Finalement, putstatic met une référence sur le tableau nouvellement créé dans le 
second champ de notre objet, i.e., le champ months. 


Fonctions variadiques 


Les fonctions variadiques utilisent en fait des tableaux: 


public static void f(int... values) 


1 
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for (int i20; i<values.length; i++) 
System.out.println(values[il); 


} 
public static void main(String[] args) 
{ 
f (1,2,3,4,5); 
} 


public static void f(int...); 
flags: ACC PUBLIC, ACC STATIC, ACC VARARGS 
Code: 
stack=3, locals-2, args size-1 
0: iconst 0 
1: istore 1 
2: iload 1 
3: aload 0 
4: arraylength 
5: if icmpge 23 
8: getstatic #2 // Field java/lang/System.out:Ljava/io/ y 
S PrintStream; 
11: aload_0 
12: iload 1 
13: iaload 
14: invokevirtual £3 // Method java/io/PrintStream.println: (1, 


17: iinc 1, 1 
20: goto 2 
23: return 


f() prend juste un tableau d'entier en utilisant aload_0 a l'offset 3. 


Puis, il prend la taille du tableau, etc. 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-4, locals-1, args size-1 
0: iconst 5 
1: newarray int 
3: dup 
4: iconst 0 
5: iconst 1 
6: iastore 
7: dup 
8: iconst 1 
9: iconst 2 
10: iastore 
11: dup 
12: iconst 2 
13: iconst 3 
14: iastore 
15: dup 
16: iconst 3 
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17: iconst_4 

18: iastore 

19: dup 

20: iconst 4 

21: iconst 5 

22: iastore 

23: invokestatic #4 // Method f:([I)V 
26: return 


Le tableau est construit dans main() en utilisant l'instruction newarray, puis il est 
rempli, et f () est appelée. 


Oh, à propos, l'objet tableau n'est pas détruit à la fin de main(). 


Il n'y a pas du tout de destructeurs en Java, car la JVM a un ramasse miette qui fait 
ceci automatiquement, lorsqu'il sent qu'il doit. 


Que dire de la méthode format () ? 


Elle prend deux arguments en entrée: une chaine et un tableau d'objets: 


public PrintStream format(String format, Object... args) 


( http://docs.oracle.com/javase/tutorial/java/data/numberformat.html ) 


Voyons: 
public static void main(String[] args) 
1 
int i-123; 
double d=123.456; 
System.out.format("int: %d double: %f.%n", i, d); 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-7, locals-4, args size-1 
0: bipush 123 
2: istore 1 
3: ldc2 w #2 // double 123.456d 
6: dstore 2 
7: getstatic #4 // Field java/lang/System.out:Ljava/iov 
y /PrintStream; 
10: ldc #5 // String int: %d double: %f.%n 
12: iconst 2 
13: anewarray #6 // class java/lang/Object 
16: dup 
17: iconst_0 
18: iload 1 
19: invokestatic #7 // Method java/lang/Integer.valueOf: (1, 


y )Ljava/lang/Integer; 
22: aastore 
23: dup 
24: iconst_1 
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25: dload_2 

26: invokestatic #8 // Method java/lang/Double.valueOf:(D)7 
& Ljava/lang/Double; 

29: aastore 


30: invokevirtual #9 // Method java/io/PrintStream. format: (7 
y Ljava/lang/String; [Ljava/lang/Object; )Ljava/io/PrintStream; 

33: pop 

34: return 


Donc, les valeurs des types int et double sont d’abord convertis en objets Integer 
et Double en utilisant les méthodes valueOf. 


La méthode format() nécessite un objet de type Object en entrée, et comme 
Integer et Double sont dérivées de la classe racine Object, ils conviennent comme 
éléments du tableau en entrée. 


D'un autre cóté, un tableau est toujours homogéne, i.e., il ne peut pas contenir 
d'éléments de types différents, ce qui rend impossible de pousser des valeurs int 
et double dedans. 


Un tableau d'objets Object est créé à l'offset 13, un objet Integer est ajouté au 
tableau à l'offset 22, et un objet Double est ajouté au tableau à l'offset 29. 


La pénultieme instruction pop supprime l'élément du TOS, donc lorsque return est 
exécuté, la pile se retrouve vide (ou balancée). 


Tableaux bi-dimensionnels 


Les tableaux bidimensionnels en Java sont juste des tableaux unidimensionnel de 
références sur d'autres tableaux uni-dimensionnels. 


Créons un tableau bi-dimensionnel: 


public static void main(String[] args) 
{ 
int[][] a = new int[5][10]; 
a[1][2]=3; 


} 


public static void main(java.lang.String[]); 

flags: ACC PUBLIC, ACC STATIC 

Code: 
stack-3, locals-2, args size-1 

0: iconst 5 

1: bipush 10 

3: multianewarray +2, 2 // class "[[I" 
7: astore 1 

8: aload 1 

9: iconst 1 
10: aaload 
11: iconst 2 
12: iconst 3 
13: iastore 
14: return 
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Il est créé en utilisant l'instruction mul tianewarray : le type de l'objet et ses dimen- 
sions sont passés comme opérandes. 


La taille du tableau (10*5) est laissée dans la pile (en utilisant les instructions iconst_5 
et bipush). 


Une référence à la line #1 est chargée à l'offset 10 (iconst_1 et aaload). 
La colonne est choisie en utilisant iconst 2 à l'offset 11. 

La valeur à écrire est mise à l'offset 12. 

iastore en 13 écrit l'élément du tableau. 


Comment un élément est-il accédé? 


public static int get12 (int[][] in) 
i 


) 


return in[1][2]; 


public static int get12(int[][]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack-2, locals-1, args size-1 

: aload 0 

iconst 1 

aaload 

iconst 2 

iaload 

ireturn 


Ui 5 0) N HG © 


Un référence sur la ligne du tableau est chargée à l'offset 2, la colonne est mise à 
l'offset 3, puis iaload charge l'élément du tableau. 


Tableaux tri-dimensionnels 


Les tableaux tridimensionnels sont simplement des tableaux unidimensionnels de 
tableaux de références sur des tableaux unidimensionnels de références de tableaux 
unidimensionnels. 


public static void main(String[] args) 


1 
int[1[1[1 a = new int[5][10][15]; 
a[11[21[3]24; 
get elem(a); 

} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack=3, locals-2, args size-1 
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0: iconst_5 

1: bipush 10 

3: bipush 15 

5: multianewarray #2, 3 // class "[[[I" 
9: astore 1 

10: aload 1 

11: iconst 1 

12: aaload 

13: iconst 2 

14: aaload 

15: iconst 3 

16: iconst 4 

17: iastore 

18: aload 1 

19: invokestatic #3 // Method get elem: ([[[I)I 
22: pop 
23: return 


Maintenant, il faut deux instructions aaload pour trouver la bonne référence : 


public static int get elem (int[][][] a) 
1 


) 


return a[1][2][3]; 


public static int get elem(int[1[1[1); 
flags: ACC PUBLIC, ACC STATIC 
Code: 

stack-2, locals-1, args size-1 

: aload 0 

iconst 1 

aaload 

iconst 2 

aaload 

iconst 3 

iaload 

ireturn 


- OU! À W NN H © 


Résumé 


Est-il possible de faire un débordement de tableau en Java? 


Non, car la longueur du tableau est toujours présente dans l'objet tableau, les li- 
mites du tableau sont contrôlées, et une exception est levée en cas d'accès hors 
des limites. 


Il n'y a pas de tableaux multi-dimensionnels en Java au sens de C/C++, donc Java 
n'est pas très bien équipé pour des calculs scientifiques rapides. 
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4.1.14 Chaines 
Premier exemple 


Les chaines sont des objets et sont construites de la méme maniére que les autres 
objets (et tableaux). 


public static void main(String[] args) 


1 
System.out.println("What is your name?"); 
String input = System.console().readLine(); 
System.out.println("Hello, "+input); 

} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=3, locals-2, args size-1 

0: getstatic #2 // Field java/lang/System.out:Ljava/io/7 
y PrintStream; 

3: ldc 33 // String What is your name? 

5: invokevirtual £4 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 

8: invokestatic #5 // Method java/lang/System.console:()7 
$ Ljava/io/Console; 

11: invokevirtual #6 // Method java/io/Console.readLine:()7 
y Ljava/lang/String; 

14: astore 1 

15: getstatic #2 // Field java/lang/System.out:Ljava/io/7 
S PrintStream; 

18: new #7 // class java/lang/StringBuilder 

21: dup 

22: invokespecial +8 // Method java/lang/StringBuilder. "</ 
S init>":()V 

25: ldc #9 // String Hello, 

27: invokevirtual #10 // Method java/lang/StringBuilder. 7 
y append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 

30: aload_1 

31: invokevirtual +10 // Method java/lang/StringBuilder. 2 
«S append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 

34: invokevirtual £11 // Method java/lang/StringBuilder. ? 
y toString:()Ljava/lang/String; 

37: invokevirtual #4 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 

40: return 


La méthode readLine() est appelée à l'offset 11, une référence sur la chaine (qui 
est fournie par l'utilisateur) est stockée sur le TOS. 


À l'offset 14, la référence sur la chaîne est stockée dans le slot 1 du LVA. 


La chaine que l'utilisateur a entré est rechargée à l'offset 30 et concaténée avec la 
chaîne «Hello, » en utilisant la classe StringBuilder. 


La chaine construite est ensuite affichée en utilisant println à l'offset 37. 
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Second exemple 


Un autre exemple: 


public class strings 


{ 


public static char test (String a) 

: return a.charAt(3); 

}; 

public static String concat (String a, String b) 
| return a+b; 


public static char test(java.lang.String); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-1, args size-1 
0: aload 0 
1: iconst 3 
2: invokevirtual +2 // Method java/lang/String.charAt: (I)C 
5: ireturn 


La concaténation de chaines est réalisée en utilisant StringBuilder : 


public static java.lang.String concat(java.lang.String, java.lang.String) 


io 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-2, locals-2, args size-2 
0: new #3 // class java/lang/StringBuilder 
3: dup 
4: invokespecial +4 // Method java/lang/StringBuilder."</ 
S init>":()V 
7: aload 0 
8: invokevirtual #5 // Method java/lang/StringBuilder. ? 
y append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 
11: aload_1 
12: invokevirtual £5 // Method java/lang/StringBuilder. ? 
y append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 
15: invokevirtual £6 // Method java/lang/StringBuilder. ? 


y toString: ()Ljava/lang/String; 
18: areturn 


Un autre exemple: 


public static void main(String[] args) 
{ 
String s="Hello!"; 
int n=123; 
System.out.println("s=" + s +" nz" + n); 
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) 


À nouveau, les chaines sont construites en utilisant la classe StringBuilder et sa 
méthode append, puis la chaîne construite est passée à println: 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=3, locals-3, args size-1 
0: ldc #2 // String Hello! 
2: astore 1 
3: bipush 123 
5: istore 2 
6: getstatic #3 // Field java/lang/System.out:Ljava/io/7 
y PrintStream; 
9: new #4 // class java/lang/StringBuilder 
12: dup 
13: invokespecial #5 // Method java/lang/StringBuilder."</ 
S init»":()V 
16: ldc #6 // String s= 
18: invokevirtual #7 // Method java/lang/StringBuilder. 2 
y append: (Ljava/lang/String; )Ljava/lang/StringBuilder; 
21: aload 1 
22: invokevirtual #7 // Method java/lang/StringBuilder. 7 
«S append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 
25: ldc #8 // String n= 
27: invokevirtual #7 // Method java/lang/StringBuilder. 2 
y append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 
30: iload_2 
31: invokevirtual #9 // Method java/lang/StringBuilder. 7 
s append: (I)Ljava/lang/StringBuilder; 
34: invokevirtual £10 // Method java/lang/StringBuilder. ? 
y toString: ()Ljava/lang/String; 
37: invokevirtual #11 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 
40: return 


4.1.15 Exceptions 
Retravaillons un peu notre exemple Month (4.1.13 on page 883) : 


Listing 4.10 : IncorrectMonthException.java 


public class IncorrectMonthException extends Exception 


1 


private int index; 


public IncorrectMonthException(int index) 


1 


this.index = index; 


} 
public int getIndex() 
{ 
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return index; 


Listing 4.11 : Month2.java 


class Month2 


1 
public static String[] months = 
1 
"January", 
"February", 
"March", 
"April", 
"May" , 
"June", 
"July", 
"August", 
"September", 
"October", 
"November", 
"December" 
s 
public static String get month (int i) throws 2 
& IncorrectMonthException 
1 
if (i«0 || i>11) 
throw new IncorrectMonthException(i); 
return months[i]; 
h 
public static void main (String[] args) 
1 
try 
1 
System.out.println(get month(100)); 
catch(IncorrectMonthException e) 
1 
System.out.println("incorrect month index: "+ e.7 
s getIndex()); 
e.printStackTrace(); 
} 
NH 
} 


En gros, IncorrectMonthException.class possède juste un objet constructeur et 
une méthode getter. 


La classe IncorrectMonthException est dérivée d'Exception, donc le constructeur 
de 
IncorrectMonthException appelle d'abord le constructeur de la classe Exception, 
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puis il met la valeur entiére en entrée dans l'unique champ de la classe IncorrectMonthException: 


public IncorrectMonthException(int); 
flags: ACC PUBLIC 
Code: 
stack-2, locals-2, args size-2 

0: aload 0 
1: invokespecial £1 // Method java/lang/Exception."<init/ 

& >": (JV 
4: aload 0 
5: iload 1 
6: putfield #2 // Field index:I 
9: return 


getIndex() est simplement un getter. Une référence sur IncorrectMonthException 
est passée dans le slot zéro du LVA (this), aload 0 le prend, getfield charge une 
valeur entiére depuis l'objet, ireturn la renvoie. 


public int getIndex(); 
flags: ACC PUBLIC 


Code: 
stack=1, locals-1, args size=1 
0: aload 0 
1: getfield #2 // Field index:I 
4: ireturn 


Maintenant, regardons get month() dans Month2. class : 
Listing 4.12 : Month2.class 


public static java.lang.String get month(int) throws 7 
s IncorrectMonthException; 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=3, locals-1, args size-1 
0: iload 0 
1: iflt 10 
4: iload 0 
5: bipush 11 
7: if_icmple 19 
10: new #2 // class IncorrectMonthException 
13: dup 
14: iload 0 
15: invokespecial £3 // Method IncorrectMonthException. "</ 
S init>":(I)V 
18: athrow 
19: getstatic 34 // Field months: [Ljava/lang/String; 
22: iload 0 
23: aaload 


24: areturn 


iflt à l'offset 1 est if less than. 


Dans le cas d'un index invalide, un nouvel objet est créé en utilisant l'instruction new 
à l'offset 10. 
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Le type de l'objet est passé comme un opérande à l'instruction (qui est IncorrectMonthException). 


Ensuite, son constructeur est appelé et l'index est passé via le TOS (offset 15). 


Lorsque le contróle du flux se trouve à l'offset 18, l'objet est déjà construit, donc 
maintenant l'instruction athrow prend une référence sur l'objet nouvellement construit 
et indique à la JVM de trouver le gestionnaire d'exception approprié. 


L'instruction athrow ne renvoie pas le contrôle du flus ici, donc à l'offset 19 il y a un 
autre bloc de base, non relatif aux exceptions, oü nous pouvons aller depuis l'offset 
7. 


Comment fonctionnent les gestionnaires? 
main() in Month2.class: 
Listing 4.13 : Month2.class 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=3, locals-2, args size-1 
0: getstatic #5 // Field java/lang/System.out:Ljava/io/7 
S PrintStream; 
3: bipush 100 
5: invokestatic #6 // Method get month: (I)Ljava/lang/2 
S String; 
8: invokevirtual +7 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 
11: goto 47 
14: astore 1 
15: getstatic #5 // Field java/lang/System.out:Ljava/io/7 
y PrintStream; 
18: new #8 // class java/lang/StringBuilder 
21: dup 
22: invokespecial #9 // Method java/lang/StringBuilder."</ 
V init>":()V 
25: ldc #10 // String incorrect month index: 
27: invokevirtual #11 // Method java/lang/StringBuilder. / 
y append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 
30: aload_1 
31: invokevirtual +12 // Method IncorrectMonthException. + 
y getIndex:()I 
34: invokevirtual £13 // Method java/lang/StringBuilder. 2 
s append: (I)Ljava/lang/StringBuilder; 
37: invokevirtual £14 // Method java/lang/StringBuilder. ? 
y toString: ()Ljava/lang/String; 
40: invokevirtual #7 // Method java/io/PrintStream.println: (2 
y Ljava/lang/String;)V 
43: aload_1 
44: invokevirtual +15 // Method IncorrectMonthException. 2 
Y printStackTrace:()V 
47: return 


Exception table: 
from to target type 
0 11 14 Class IncorrectMonthException 
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Ici se trouve la table Exception, qui définit que de l'offset O à 11 (inclus), une 
exception 
IncorrectMonthException peut se produire, et si cela se produit, le contróle du flux 
sera passé à l'offset 14. 


En effet, le programme principal se termine à l'offset 11. 


À l'offset 14, le gestionnaire commence. Il n'est pas possible d'arriver ici, il n'y a pas 
de saut conditionnel/inconditionnel à cet endroit. 


Mais la JVM transférera le flux d'exécution ici en cas d'exception. 


Le tout premier astore 1 (en 14) prend la référence en entrée sur l'objet exception 
et la stocke dans le slot 1 du LVA. 


Plus tard, la méthode getIndex() (de cet objet exception) sera appelée à l'offset 
31. 


La référence sur l'objet exception courant est passée juste avant cela (offset 30). 


Le reste du code effectue juste de la manipulation de chaîne: d'abord. la valeur en- 
tiére renvoyée par getIndex() est convertie en chaine par la méthode toString(), 
puis est concaténée avec la chaine de texte «incorrect month index: » (comme nous 
l'avons vu avant), enfin println() et printStackTrace() sont appelées. 


Après la fin de printStackTrace(), l'exception est gérer et nous pouvons continuer 
avec l'exécution normale. 


À l'offset 47 il y a un return qui termine la fonction main(), mais il pourrait y avoir 
n'importe quel autre code qui serait exécuté comme si aucune exception n'avait été 
déclenchée. 


Voici un exemple de la facon dont IDA montre les intervalles d'exceptions: 


Listing 4.14 : tiré d'un fichier .class quelconque trouvé sur mon ordinateur 


.catch java/io/FileNotFoundException from met001 335 to met001_3601 
using met001 360 
.catch java/io/FileNotFoundException from met001 185 to met001 214\ 
using met001 214 
.catch java/io/FileNotFoundException from met001 181 to met001 192\ 
using met001 195 
.catch java/io/FileNotFoundException from met001 155 to met001 176\ 
using met001 176 
.catch java/io/FileNotFoundException from met001 83 to met001 129 using 
GoN 
met001 129 
.catch java/io/FileNotFoundException from met001 42 to met001 66 using 7 
SN 
met001 69 
.catch java/io/FileNotFoundException from met001 begin to met001 37N 
using met001 37 


4.1.16 Classes 


Classe simple: 
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Listing 4.15 : test.java 


public class test 


{ 
public static int a; 
private static int b; 
public test() 
{ 
a=0; 
b=0; 
} 
public static void set_a (int input) 
{ 
a=input; 
} 
public static int get a () 
1 
return a; 
public static void set b (int input) 
1 
b=input; 
} 
public static int get_b () 
{ 
return b; 
} 
} 


Le constructeur met simplement les deux champs a zéro: 


public test(); 
flags: ACC PUBLIC 


Code: 
stack-1, locals-1, args size-1 

0: aload 0 
1: invokespecial £1 // Method java/lang/Object."<init>":() 7 

GV 
4: iconst_0 
5: putstatic #2 // Field a:I 
8: iconst_0 
9: putstatic #3 // Field b:I 
12: return 

Setter dea: 


public static void set_a(int); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: iload 0 
1: putstatic #2 // Field a:I 


4: return 
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Getter dea: 


public static int get a(); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=1, locals=0, args size-0 
0: getstatic #2 // Field a:I 
3: ireturn 
Setter deb: 


public static void set b(int); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack-1, locals-1, args size-1 
0: iload 0 
1: putstatic 33 // Field b:I 
4: return 
Getter de b : 


public static int get b(); 
flags: ACC PUBLIC, ACC STATIC 


Code: 
stack=1, locals=0, args size-0 
0: getstatic #3 // Field b:I 
3: ireturn 


Il n'y a aucune différence dans le code qui fonctionne avec des champs publics ou 
privés. 


Mais ce type d'information est présent dans le fichier .class et il n'est pas possible 
d'accéder aux champs privés depuis n'importe oü. 


Créons un objet et appelons sa méthode: 


Listing 4.16 : ex1.java 


public class exl 


1 
public static void main(String[] args) 
t 
test obj=new test(); 
obj.set a (1234); 
System.out.println(obj.a); 
} 
} 


public static void main(java.lang.String[]); 
flags: ACC PUBLIC, ACC STATIC 
Code: 
stack-2, locals-2, args size-1 
0: new #2 // class test 
3: dup 
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4: invokespecial +3 // Method test."<init>":()V 

7: astore 1 

8: aload 1 

9: pop 

10: sipush 1234 

13: invokestatic #4 // Method test.set_a:(I)V 

16: getstatic #5 // Field java/lang/System.out:Ljava/io/7 
y PrintStream; 

19: aload 1 

20: pop 

21: getstatic 3*6 // Field test.a:I 

24: invokevirtual +7 // Method java/io/PrintStream.println: (2 
S I)V 

27: return 


L'instruction new crée un objet, mais n'appelle pas le constructeur (il est appelé à 
l'offset 4). 


La méthode set a() est appelée à l'offset 16. 


Le champ a est accédé en utilisant l'instruction getstatic à l'offset 21. 


4.1.17 Correction simple 
Premier exemple 


Procédons avec une simple de táche de modification de code. 


public class nag 


1 
public static void nag screen() 
1 
System.out.println("This program is not registered"); 
}; 
public static void main(String[] args) 
1 
System.out.println("Greetings from the mega-software"); 
nag screen(); 
} 
} 


Comment pourrions-nous supprimer l'affichage de la chaine «This program is not 
registered » ? 


Chargeons le fichier .class dans IDA : 


2 178 
* (618 
* 182 


* Hz7 
2 1222 
222 
222 


2 1178 
* |e18 
* H82 
* (184 


* Hz7 


808 662 | 
883 
888 805 


??? 222+ 
??? 277+ 


668 662 
885 
666 664 


666 666 
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; Segment type: Pure code 


.method public static nag_screen()U 
-limit stack 2 
-line 4 
getstatic java/lang/System.out Ljava/io/PrintStream; ; CODE XREF: main+8yP 
ldc "This program is not registered" 
invokevirtual java/io/PrintStream.printin(Ljava/lang/String;)U 
-line 5 
return 
.end method 


; Segnent type: Pure code 


-method public static main([Ljava/lang/String;)U 
-limit stack 2 
-limit locals 1 
-line 8 
getstatic java/lang/System.out Ljava/io/PrintStream; 
lde "Greetings from the mega-software" 
invokevirtual java/io/PrintStream.printin(Ljava/lang/String;)U 
-line 9 
invokestatic nag.nag screen()U 
-line 18 
return 


Fig. 4.1: IDA 


Modifions le premier octet de la fonction à 177 (qui est l'opcode de l'instruction 


return): 
; Segnent type: Pure code 
.method public static nag screen()U 
-limit stack 2 
| -line 4 
nag_screen: ; CODE XREF: main+8yP 
* (177 return 
* [098 
* |ee2 
* 1918 003 ldc "This program is not registered" 
* 82 006 664 invokevirtual java/io/PrintStream.printin(Ljava/lang/String;)U 
-line 5 
e l177 return 


2?? 27? 777+ „end method 
(227 ??? 222% 


222 


Mais ca ne fonctionne pas (JRE 1.7) : 


Exception in thread "main" java.lang.VerifyError: Expecting a stack map 
\ frame 
Exception Details: 
Location: 
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nag.nag screen()V (1: nop 
Reason: 

Error exists in the bytecode 
Bytecode: 

0000000: b100 0212 03b6 0004 b1 


at java.lang.Class.getDeclaredMethodsO(Native Method) 

at java.lang.Class.privateGetDeclaredMethods(Class.java:2615) 

at java.lang.Class.getMethod0(Class.java:2856) 

at java.lang.Class.getMethod(Class.java:1668) 

at sun. launcher.LauncherHelper.getMainMethod(LauncherHelper.java2 


VS :494) 


at sun. Launcher.LauncherHelper. checkAndLoadMain(LauncherHelper.javayv 


V 7486) 


Peut-étre que la JVM a d'autres tests relatifs à l'état de la pile. 


OK, modifions différemment en supprimant l'appel a nag() : 


; Segment type: Pure code 


-method public static main([Ljava/lang/String;)U 


-limit stack 2 
-limit locals 1 


182 009 004 invokevirtual jaua/io/PrintStream.printin(Ljava/lang/String;)U 


-line 8 
. 
* (018 005 ldc "Greetings from the mega-software" 
. 
-line 9 
* (008 nop 
* jona nop 
* [ooo nop 
-line 18 
e 77 return 


Fig. 4.3: IDA 


0 est I’ opcode de NOP. 
Maintenant, ca fonctionne! 


Second exemple 


Un autre exemple simple de crackme: 


178 808 662 getstatic java/lang/System.out Ljava/io/PrintStream; 


public class password 


1 


public static void main(String[] args) 


{ 


System.out.println("Please enter the password"); 

String input = System.console().readLine(); 

if (input.equals("secret")) 
System.out.println("password is correct"); 
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else 
System.out.println("password is not correct"); 


Chargeons le dans IDA : 


; Segment type: Pure code 
-nethod public static main([Ljava/lang/String;)U 
-limit stack 2 
-limit locals 2 


-line 3 
* H78 008 002 getstatic java/lang/System.out Ljava/io/PrintStream; 
* le18 803 ldc "Please enter the password" 
* (182 008 004 invokevirtual java/io/PrintStream.printlin(Ljava/lang/String;)U 
-line 4 
* 84 666 005 invokestatic java/lang/System.console()Ljava/io/Console; 
* 182 008 006 invokevirtual java/io/Console.readLine()Ljava/lang/String; 
* (076 astore 1 ; met082_slot001 
-line 5 
* (043 aload 1 ; met662_slot661 
* le18 007 lde "secret" 
* 82 008 008 invokevirtual java/lang/String.equals(Ljava/lang/0bject;)Z 
r--* [153 666 614 ifeq 
: -line 6 
ı © [178 688 002 getstatic java/lang/System.out Ljava/io/PrintStream; 
| *]eis 669 ldc "password is correct" 
1 © [182 006 094 invokevirtual java/io/PrintStream.printlin(Ljava/lang/String;)U 
ı -ê f167 000 011 goto met662_43 
: -line 8 
I 
i : ; CODE XREF: main*211j 
' 178 666 662 -stack use locals 
i locals Object java/lang/String 
à -end stack 
- pe getstatic java/lang/System.out Ljava/io/PrintStream; 
* |e18 818 ldc "password is not correct" 
2 M82 066 004 invokevirtual java/io/PrintStream.println(Ljava/lang/String;)U 
-line 9 


Fig. 4.4: IDA 


Nous voyons ici l'instruction ifeq qui effectue le travail. 


Son nom signifie if equal (si égal), et c'est mal-nommé, un meilleur nom serait ifz 
(if zero, si zéro), i.e, si la valeur sur le TOS est zéro, alors effectuer le saut. 


Dans notre exemple, le saut est fait si le mot de passe est incorrect (la méthode 
equals renvoie False, qui est 0). 


La toute premiére idée est de patcher cette instruction. 
Il y a deux octets dans l'opcode de ifeq, qui encode l'offset du saut. 


Pour transformer cette instruction en NOP, nous devons mettre la valeur 3 dans 
le 3éme octet (car ajouter 3 à l'adresse courante sautera toujours à l'instruction 
suivante, puisque la longueur de l'instruction ifeq est de 3 octets) : 


* (178 
* (018 
* 1182 


2 (184 
2 1182 
* (076 


2 (043 
* (018 
* (182 
2 153 


Y 772771 
. 


178 
* (018 
2 (182 
2 (167 


178 


818 
* (182 


888 
883 
666 


667 
666 
666 


666 
669 
666 
666 


616 
888 


662 


664 


8685 
886 


668 
663 


662 


664 
611 


662 


664 


; Segment type: Pure code 


-method public static main([Ljava/lang/String;)U 
-limit stack 2 
-limit locals 2 
-line 3 
getstatic java/lang/System.out Ljava/io/PrintStream; 
ldc "Please enter the password" 
invokevirtual jaua/io/PrintStream.printin(Ljava/lang/String;)U 
-line 4 
invokestatic java/lang/System.console()Ljava/io/Console; 
invokevirtual java/io/Console.readLine()Ljava/lang/String; 
astore 1 ; met882 slot801 
-line 5 
aload 1 ; met662_slot661 
ldc "secret" 
invokevirtual java/lang/String.equals(Ljava/lang/0bject;)2 
ifeq 
-line 6 


: ; CODE XREF: main+211j 
getstatic java/lang/System.out Ljava/io/PrintStream; 
ldc “password is correct" 
invokevirtual java/io/PrintStream.printin(Ljava/lang/String;)U 
goto met802 ^3 
-line 8 
-stack use locals 
locals Object java/lang/String 
.end stack 
getstatic java/lang/System.out Ljava/io/PrintStream; 
ldc “password is not correct" 
invokevirtual java/io/PrintStream.printin(Ljava/lang/String;)U 
-line 9 


Fig. 4.5: IDA 


Ceci ne fonctionne pas (JRE 1.7) : 
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Exception in thread "main" java.lang.VerifyError: Expecting a stackmap Y 
S frame at branch target 24 
Exception Details: 


Location: 
password.main([Ljava/lang/String;)V Q21: ifeq 
Reason: 
Expected stackmap frame at this location. 
Bytecode: 
0000000: b200 0212 03b6 0004 b800 05b6 0006 4c2b 
0000010: 1207 b600 0899 0003 b200 0212 09b6 0004 
0000020: a700 Obb2 0002 120a b600 04b1 


Stackmap Table: 


append_frame(@35, Object [#20] ) 
same_frame(@43) 


at 
at 
at 
at 
at 


java.lang.Class.getDeclaredMethods0 (Native Method) 
java.lang.Class.privateGetDeclaredMethods(Class.java:2615) 
java.lang.Class.getMethod0 (Class.java:2856) 
java.lang.Class.getMethod(Class.java:1668) 

sun. launcher.LauncherHelper.getMainMethod(LauncherHelper. java?” 
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y :494) 
at sun. Launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.javayv 
y 1486) 


Mais il faut mentionner que ceci fonctionnait avec le JRE 1.6. 


Nous pouvons aussi essayer de remplacer les 3 octets de l'opcode de ifeq par des 
octets à zéro (NOP), mais ca ne fonctionne toujours pas. 


Il semble qu'il y a plus de tests de l'état de la pile en JRE 1.7. 


OK, remplacons tout l'appel à la méthode equals avec l'instruction iconst 1 et 
quelques NOPs: 


; Segment type: Pure code 
-nethod public static main([Ljava/lang/String;)U 
-limit stack 2 
-limit locals 2 


-line 3 
* [178 600 002 getstatic java/lang/System.out Ljava/io/PrintStream; 
* 1018 663 ldc "Please enter the password" 
* [182 688 004 invokevirtual jaua/io/PrintStream.printin(Ljava/lang/String;)U 

-line 4 
^ (184 008 885 invokestatic java/lang/System.console()Ljava/io/Console; 
* [182 000 006 invokevirtual jaua/io/Console.readLine()Ljava/lang/String; 
* 1076 astore 1 ; met662_slot661 

-line 5 
* joos iconst 1 
* [000 nop 
* jona nop 
* jana nop 
* jona nop 
* jana nop 
* (153 088 014 ifeq met882 35 

-line 6 
* [178 000 002 getstatic java/lang/System.out Ljava/io/PrintStream; 
* 1018 889 ldc "password is correct" 
* (182 000 885 invokevirtual jaua/io/PrintStream.printin(Ljava/lang/String;)U 
* (167 066 011 goto met002_43 

-line 8 

met882 35: ; CODE XREF: main+211j 
178 666 662 -Stack use locals 
locals Object java/lang/String 
-end stack 


Fig. 4.6: IDA 


Il doit toujours y avoir 1 sur le TOS lorsque l'instruction ifeq est exécutée, ainsi ifeq 
ne fera jamais le saut. 


Ceci fonctionne. 
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4.1.18 Résumé 
Que manque-t-il à Java par rapport à C/C++? 
* Structures: utiliser les classes. 
* Unions; utiliser des hiérarchies de classes. 


* Types de données non signés. À propos, ceci rend les algorithmes cryptogra- 
phiques quelque peu plus difficile à implémenter en Java. 


* Pointeurs de fonction. 


Chapitre 5 


Trouver des choses 
importantes/intéressantes 
dans le code 


Le minimalisme n'est pas une caractéristique prépondérante des logiciels modernes. 


Pas parce que les programmeurs écrivent beaucoup, mais parce que de nombreuses 

bibliothèques sont couramment liées statiquement aux fichiers exécutable. Si toutes 

les bibliotheques externes étaient déplacées dans des fichiers DLL externes, le monde 
serait différent. (Une autre raison pour C++ sont la STL et autres bibliothéques tem- 
plates.) 


Ainsi, il est trés important de déterminer l'origine de la fonction, si elle provient d'une 
bibliothéque standard ou d'une bibliothéque bien connue (comme Boost!, libpng?), 
OU Si elle est liée à ce que l'on essaye de trouver dans le code. 


Il est simplement absurde de tout récrire le code en C/C++ pour trouver ce que l'on 
cherche. 


Une des premiéres táches d'un rétro-ingénieur est de trouver rapidement le code 
dont il a besoin. 


Le dés-assembleur IDA nous permet de chercher parmi les chaines de texte, les 
séquences d'octets et les constantes. Il est méme possible d'exporter le code dans 
un fichier texte .Ist ou .asm et d'utiliser grep, awk, etc. 


Lorsque vous essayez de comprendre ce que fait un certain code, ceci peut étre 
facile avec une bibliothéque open-source comme libpng. Donc, lorsque vous voyez 
certaines constantes ou chaínes de texte qui vous semblent familiéres, il vaut tou- 
jours la peine de les googler. Et si vous trouvez le projet open-source oü elles sont 
utilisées, alors il suffit de comparer les fonctions. Ceci peut permettre de résoudre 
certaines parties du probléme. 


lhttp://www.boost.org/ 
?http: //www.libpng.org/pub/png/libpng.html 
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Par exemple, si un programme utilise des fichiers XML, la premiéres étape peut-étre 
de déterminer quelle bibliothéque XML est utilisée pour le traitement, puisque les 
bibliothéques standards (ou bien connues) sont en général utilisées au lieu de code 
fait maison. 


Par exemple, j'ai essayé une fois de comprendre comment la compression/décom- 
pression des paquets réseau fonctionne dans SAP 6.0. C'est un logiciel gigantesque, 
mais un .PDB détaillé avec des informations de débogage est présent, et c'est pra- 
tique. J'en suis finalement arrivé à l'idée que l'une des fonctions, qui était appelée 
par CsDecomprLZC, effectuait la décompression des paquets réseau. Immédiate- 
ment, j'ai essayé de googler le nom et rapidement trouvé que la fonction était utili- 
sée dans MaxDB (c'est un projet open-source de SAP) ?. 


http://www.google.com/search?q=CsDecomprLzC 


Étonnement, les logiciels MaxDB et SAP 6.0 partagent du code comme ceci pour la 
compression/ décompression des paquets réseau. 


5.1 Identification de fichiers exécutables 


5.1.1 Microsoft Visual C++ 


Les versions de MSVC et des DLLs peuvent étre importées: 


Marketing ver. | Internal ver. | CL.EXE ver. | DLLs imported | Release date 

6 6.0 12.00 msvcrt.dll June 1998 
msvcp60.dll 

.NET (2002) 7.0 13.00 msvcr70.dll February 13, 2002 
msvcp70.dll 

.NET 2003 7.1 13.10 msvcr7 1.dll April 24, 2003 
msvcp71.dll 

2005 8.0 14.00 msvcr80.dil November 7, 2005 
msvcp80.dll 

2008 9.0 15.00 msvcr90.dll November 19, 2007 
msvcp90.dll 

2010 10.0 16.00 msvcr100.dll April 12, 2010 
msvcp100.dil 

2012 11.0 17.00 msvcr110.dil September 12, 2012 
msvcp110.dil 

2013 12.0 18.00 msvcr120.dil October 17, 2013 
msvcp120.dil 


msvcp*.dll contient des fonctions relatives à C++, donc si elle est importées, il s'agit 
probablement d'un programme C++. 


Mangling de nom 


Les noms commencent en général par le symbole ?. 


3Plus sur ce sujet dans la section concernée (8.12.1 on page 1141) 
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Vous trouverez plus d'informations le mangling de nom de MSVC ici: 3.21.1 on page 699. 


5.1.2 GCC 

À part les cibles *NIX, GCC est aussi présent dans l'environnement win32, sous la 
forme de Cygwin et MinGW. 

Mangling de nom 

Les noms commencent en général par le symbole Z. Vous trouverez plus d'informa- 
tions le mangling de nom de GCC ici: 3.21.1 on page 699. 

Cygwin 


cygwin1.dll est souvent importée. 


MinGW 


msvcrt.dll peut être importée. 


5.1.3 Intel Fortran 


libifcoremd.dll, libifportmd.dll et libiomp5md.dll (support OpenMP) peuvent être im- 
portées. 


libifcoremd.dll a beaucoup de fonctions préfixées par for , qui signifie Fortran. 


5.1.4 Watcom, OpenWatcom 
Mangling de nom 


Les noms commencent usuellement par le symbole W. 


Par exemple, ceci est la facon dont la méthode nommées «method » de la classe 
«class » qui n'a pas d'argument et qui renvoie void est encodée: 


W?method$ class$n v 


5.1.5 Borland 


Voici un exemple de mangling de nom de Delphi de Borland et de C++Builder: 


@TApplication@IdleAction$qv 
@TApplication@ProcessMDIAccels$qp6tagMSG 
@TModule@$bctr$qpcpvt1l 

@TModule@$bdt r$qv 
@TModule@ValidWindow$qp14TWindowsObject 
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@TrueBitmap@$bctr$qpcl 
@TrueBitmap@$bctr$qpvl 
@TrueBitmap@$bctr$qiilll 


Les noms commencent toujours avec le symbole @, puis nous avons le nom de la 
classe, de la méthode et les types des arguments de méthode encodés. 


Ces noms peuvent étre dans des imports .exe, des exports .dll, des données de 
débogage, etc. 


Les Borland Visual Component Libraries (VCL) sont stockées dans des fichiers .bpl 
au lieu de .dll, par exemple, vclI50.dll, rtl60.dll. 


Une autre DLL qui peut étre importée: BORLNDMM.DLL. 


Delphi 


Presque tous les exécutables Delpi ont la chaine de texte «Boolean» au début de 
leur segment de code, ainsi que d'autres noms de type. 


Ceci est le début trés typique du segment CODE d'un programme Delphi, ce bloc 
vient juste aprés l'entéte de fichier win32 PE: 


04 10 40 00 03 07 42 6f 6f 6c 65 61 Ge 01 00 00 |..@...Boolean... | 
00 00 01 00 00 00 00 10 40 00 05 46 61 6c 73 65  |........ Q..False| 
04 54 72 75 65 8d 40 00 2c 10 40 00 09 08 57 69 |.True.@.,.@...Wi| 
64 65 43 68 61 72 03 00 00 00 00 ff ff 00 00 90 |deChar.......... | 
44 10 40 00 02 04 43 68 61 72 01 00 00 00 00 ff |D.@...Char...... | 


00 00 00 90 58 10 40 00 01 08 53 6d 61 6c 6c 69 | X.@...Smallil 
6e 74 02 00 80 ff ff ff 7f 00 00 90 70 10 40 00  |nt.......... p.@. | 
01 07 49 6e 74 65 67 65 72 04 00 00 00 80 ff ff |..Integer....... | 
ff 7f 8b cO 88 10 40 00 01 04 42 79 74 65 01 00 |...... Q...Byte..| 
00 00 00 ff 00 00 00 90 9c 10 40 00 01 04 57 6f  |.......... @...Wo| 
72 64 03 00 00 00 00 ff ff 00 00 90 bO 10 40 00 |rd............ @. | 
01 08 43 61 72 64 69 6e 61 6c 05 00 00 00 00 ff |..Cardinal...... | 
ff ff ff 90 c8 10 40 00 10 05 49 6e 74 36 34 00 |...... @...Int64. | 


e4 10 40 00 04 08 45 78 74 65 6e 64 65 64 02 90 ..@...Extended.. 
f4 10 40 00 04 06 44 6f 75 62 6c 65 01 8d 40 00 ..@...Double..@. 
04 11 40 00 04 08 43 75 72 72 65 6e 63 79 04 90 @...Currency.. 


..WideString0.@. 
..Variant.@.@.@. 


| 
| 
| 
.string .@.| 
| 
| 
. .OleVariant..Q.| 


28 4d 40 00 2c 4d 40 00 20 4d 40 00 68 4a 40 00 |(M@.,M@. M@.hJ@. 
84 4a 40 00 cO 4a 40 00 07 54 4f 62 6a 65 63 74 |.J@..J@..TObject | 
a4 11 40 00 07 07 54 4f 62 6a 65 63 74 98 11 40 |..@...TObject..@| 
00 00 00 00 00 00 00 06 53 79 73 74 65 6d 00 00 |........ System.. | 
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..F.System....| 
M 


cc 83 44 24 04 f8 e9 51 6c 00 00 83 44 24 04 f8 ..D$. Ql... D$..| 
e9 6f 6c 00 00 83 44 24 04 f8 e9 79 6c 00 00 cc ol...D$...yl | 
cc 21 12 40 00 2b 12 40 00 35 12 40 00 01 00 00 !.@.+.@.5.@ | 


bc 12 40 00 Oc 00 00 00 4c 11 40 00 18 4d 40 00 |..@..... L.@. .M@. | 
50 7e 40 00 5c 7e 40 00 2c 4d 40 00 20 4d 40 00 |P~@.\~@.,M@. MA. | 
6c 7e 40 00 84 4a 40 00 cO 4a 40 00 11 54 49 6e |1~@..J@..J@..TIn| 
74 65 72 66 61 63 65 64 4f 62 6a 65 63 74 8b cO |terfacedObject.. | 


73 74 65 6d 28 13 40 00 04 09 54 44 61 74 65 54 | stem( .Q. d 


d4 12 40 00 07 11 54 49 6e 74 65 72 66 61 63 65 |..@. rd 
64 4f 62 6a 65 63 74 bc 12 40 00 a0 11 40 00 00 |dObject. .@.. . | 
00 06 53 79 73 74 65 6d 00 00 8b cO 00 13 40 00 |..System...... a. | 
11 Ob 54 42 6f 75 6e 64 41 72 72 61 79 04 00 00 |..TBoundArray... | 
00 00 00 00 00 03 00 00 00 6c 10 40 00 06 53 79  |......... 1.6. .Sy| 

| 

D.| 


Les 4 premiers octets du segment de données (DATA) peuvent étre 00 00 00 00, 32 
13 8B CO ou FF FF FF FF. 


Cette information peut étre utile lorsque l'on fait face à des exécutables Delphi pré- 
parés/chiffrés. 


5.1.6 Autres DLLs connues 


* vcomp*.dll—implémentation d'OpenMP de Microsoft. 


5.2 Communication avec le monde extérieur (niveau 
fonction) 


Il est souvent recommandé de suivre les arguments de la fonction et sa valeur de 
retour dans un débogueur ou DBI. Par exemple, l'auteur a essayé une fois de com- 
prendre la signification d'une fonction obscure, qui s'est avérée étre un tri à bulles 
mal implémenté^. (Il fonctionnait correctement, mais plus lentement.) En méme 
temps, regarder les entrées et sorties de cette fonction aide instantanément à com- 
prendre ce quelle fait. 


Souvent, lorsque vous voyez une division par la multiplication (3.12 on page 636), 
mais avez oublié tous les détails du mécanisme, vous pouvez seulement observer 
l'entrée et la sortie, et trouver le diviseur rapidement. 


4https://yurichev.com/blog/weird sort KLEE/ 
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5.3 Communication avec le monde extérieur (win32) 


Parfois, il est suffisant d'observer les entrées/sorties d'une fonction pour comprendre 
ce qu'elle fait. Ainsi, vous pouvez gagner du temps. 


Accés aux fichiers et au registre: pour les analyses trés basiques, l'utilitaire, Process 
Monitor? de Sysinternals peut aider. 


Pour l'analyse basique des accés au réseau, Wireshark? peut étre utile. 


Mais vous devrez de toutes facons regarder à l'intérieur, 


Les premières choses à chercher sont les fonctions des APIs de l'OS et des biblio- 
théques standards qui sont utilisées. 


Si le programme est divisé en un fichier exécutable et un groupe de fichiers DLL, 
parfois le nom des fonctions dans ces DLLs peut aider. 


Si nous sommes intéressés par exactement ce qui peut conduire à appeler MessageBox ( ) 
avec un texte spécifique, nous pouvons essayer de trouver ce texte dans le segment 

de données, trouver sa référence et trouver les points depuis lesquels le contróle 
peut étre passé à l'appel à MessageBox() qui nous intéresse. 


Si nous parlons d'un jeu vidéo et que nous sommes intéressés par les événements 
qui y sont plus ou moins aléatoires, nous pouvons essayer de trouver la fonction 
rand() ou sa remplacante (comme l'algorithme du twister de Mersenne) et trouver 
les points depuis lesquels ces fonctions sont appelées, et plus important, comment 
les résultats sont utilisés. Un exemple: 8.3 on page 1044. 


Mais si ce n'est pas un jeu, et que rand() est toujours utilisé, il est intéressant de 
savoir pourquoi. ll a y des cas d'utilisation inattendu de rand() dans des algorithmes 
de compression de données (pour une imitation du chiffrement) : blog.yurichev.com. 


5.3.1 Fonctions souvent utilisées dans l'API Windows 


Ces fonctions peuvent être parmi les fonctions importées. Il est utile de noter que 
toutes les fonctions ne sont pas forcément utilisées dans du code écrit par le pro- 
grammeur. Beaucoup de fonctions peuvent étre appelées depuis des fonctions de 
bibliothéque et du code CRT. 


Certaines fonctions peuvent avoir le suffixe -A pour la version ASCII et -W pour la 
version Unicode. 


e Accès au registre (advapi32.dll) : RegEnumKeyEx, RegEnumValue, RegGetValue, 
RegOpenKeyEx, RegQueryValueEx. 


* Accés au text des fichiers .ini (kernel32.dll) : GetPrivateProfileString. 


* Boites de dialogue (user32.dll) : MessageBox, MessageBoxEx, CreateDialog, 
SetDlgltemText, GetDlgltemText. 


* Accés aux resources (6.5.2 on page 994) : (user32.dll) : LoadMenu. 


5http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx 
Shttp://www.wireshark.org/ 
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Réseau TCP/IP (ws2 32.dll) : WSARecv, WSASend. 


Accès fichier (kernel32.dll) : CreateFile, ReadFile, ReadFileEx, WriteFile, WriteFi- 
leEx. 


Accés haut niveau à Internet (wininet.dll) : WinHttpOpen. 


Vérifier la signature digitale d'uin fichier exécutable (wintrust.dll) : WinVerify- 
Trust. 


La bibliothéque MSVC standard (si elle est liée dynamiquement) (msvcr*.dll) : 


assert, itoa, Itoa, open, printf, read, strcmp, atol, atoi, fopen, fread, fwrite, memcmp, 


rand, strlen, strstr, strchr. 


5.3.2 Étendre la période d'essai 


Les fonctions d'accés au registre sont des cibles fréquentes pour ceux qui veulent 
essayer de craquer des logiciels avec période d'essai, qui peuvent sauvegarder la 
date et l'heure dans un registre. 


Des autres cibles courantes sont les fonctions GetLocalTime() et GetSystemTime() : 
un logiciel avec période d'essai, à chaque démarrage, doit de toutes facons vérifier 
la date et l'heure d'une certaine facon. 


5.3.3 Supprimer la boite de dialogue nag 


Une maniére répandue de trouver ce qui cause l'apparition de la boite de dialogue 
nag est d'intercepter les fonctions MessageBox(), CreateDialog() et CreateWindow(). 


5.3.4 tracer: Intercepter toutes les fonctions dans un module 
spécifique 

Il y a un point d'arrét INT3 dans tracer, qui peut étre déclenché seulement une fois, 

toutefois, il peut étre mis pour toutes les fonctions dans une DLL spécifique. 


--one-time-INT3-bp:somedll.dll!.* 


Ou, mettons un point d'arrét INT3 sur toutes les fonctions avec le préfixe xml dans 
leur nom: 


--one-time-INT3-bp:somedll.dll!xml.* 


Le revers de la médaille est que de tels points d'arrét ne sont déclenchés qu'une 
fois. Tracer montrera l'appel à une fonction, s'il se produit, mais seulement une fois. 
Un autre inconvénient—il est impossible de voir les arguments de la fonction. 


Néanmoins, cette fonctionnalité est trés utile lorsque vous avez qu'un programme 
utilise une DLL, mais que vous ne savez pas quelles fonctions sont effectivement 
utilisées. Et il y a beaucoup de fonctions. 


Par exemple, regardons ce qu'utilise l'utilitaire uptime de Cygwin: 
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tracer -l:uptime.exe --one-time-INT3-bp:cygwinl.dll!.* 


Ainsi nous pouvons voir quelles sont les fonctions de la bibliothèque cygwin1.dll qui 
sont appelées au moins une fois, et depuis ou: 


One-time INT3 breakpoint: cygwinl. 


V x6d (0x40106d)) 


One-time INT3 breakpoint: 


cygwinl 


& OEP+0xba3 (0x401ba3)) 


One-time INT3 breakpoint: 


& +0xbaa (0x401baa)) 


One-time INT3 breakpoint: 


cygwinl 


cygwinl 


4 OEP+Oxcb7 (0x401cb7)) 


One-time INT3 breakpoint: 


& +0xcbe (0x401cbe)) 


One-time INT3 breakpoint: 


Y x735 (0x401735)) 


One-time INT3 breakpoint: 


V +0x7b2 (0x4017b2)) 


One-time INT3 breakpoint: 


Y x994 (0x401994)) 


One-time INT3 breakpoint: 


V +0x7ea (0x4017ea)) 


One-time INT3 breakpoint: 


S x809 (0x401809)) 


One-time INT3 breakpoint: 


Y x839 (0x401839)) 


One-time INT3 breakpoint: 


S X139 (0x401139)) 


One-time INT3 breakpoint: 


V. x22e (0x40122e)) 


One-time INT3 breakpoint: 


S +0x236 (0x401236)) 


One-time INT3 breakpoint: 


& x25a (0x40125a)) 


One-time INT3 breakpoint: 


& +0x3b1 (0x4013b1)) 


One-time INT3 breakpoint: 


V +0x3c5 (0x4013c5)) 


One-time INT3 breakpoint: 


V +0x3e6 (0x4013e6)) 


One-time INT3 breakpoint: 


4 x4c3 (0x4014c3)) 


cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 
cygwinl 


cygwinl 


dll! main (called from uptime.exe!0EP+0 ? 


.dll! geteuid32 (called from uptime.exe! v 
.d11! getuid32 (called from uptime.exe!0EP/ 
.dll! getegid32 (called from uptime.exe! ” 
.d11! getgid32 (called from uptime.exe! OEP? 
.dll!sysconf (called from uptime.exe!0EP+0 7 
.dll!setlocale (called from uptime.exe! OEP? 
.dll! open64 (called from uptime.exe!0EP+0 7 
.dll! lseek64 (called from uptime.exe!0EP 2 
.dll!read (called from uptime.exe!0EP+0 7 
.dll!sscanf (called from uptime.exe!0EP+0 7 
.dll!uname (called from uptime.exe!0EP+0 7 
.dll!time (called from uptime.exe!0EP+0 7 
.dll!localtime (called from uptime.exe! OEP / 
.dll!sprintf (called from uptime.exe!0EP+0 
.dll!setutent (called from uptime.exe!0EP 2 
.dll!getutent (called from uptime.exe!0EP 2 
.dll!endutent (called from uptime.exe!0EP 2 


.dll!puts (called from uptime.exe!0EP+0 7 


5.4 Chaines 


5.4.1 Chaines de texte 


C/C++ 


Les chaines C normales sont terminées par un zéro (chaines ASCIIZ). 
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La raison pour laquelle le format des chaínes C est ce qu'il est (terminé par zéro) est 
apparemment historique: Dans [Dennis M. Ritchie, The Evolution of the Unix Time- 
sharing System, (1979)] nous lisons: 


A minor difference was that the unit of I/O was the word, not the 
byte, because the PDP-7 was a word-addressed machine. In practice 
this meant merely that all programs dealing with character streams 
ignored null characters, because null was used to pad a file to an even 
number of characters. 


Une différence mineure était que l'unité d'E/S était le mot, pas l'octet, car le PDP-7 
était une machine adressée par mot. En pratique, cela signifiait que tous les pro- 
grammes ayant à faire avec des flux de caractéres ignoraient le caractére nul, car 
nul était utilisé pour compléter un fichier ayant un nombre impair de caractéres. 


Dans Hiew ou FAR Manager ces chaines ressemblent à ceci: 


int main() 


1 
$; 


printf ("Hello, world!\n"); 


Fig. 5.1: Hiew 


Borland Delphi 


Une chaîne en Pascal et en Delphi de Borland est précédée par sa longueur sur 8-bit 
ou 32-bit. 


Par exemple: 


Listing 5.1 : Delphi 


CODE :00518AC8 dd 19h 
CODE:00518ACC aLoading Plea db ‘Loading... , please wait.',0 
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CODE :00518AFC dd 10h 
CODE:00518B00 aPreparingRun db 'Preparing run...',0 
Unicode 


Souvent, ce qui est appelé Unicode est la méthode pour encoder des chaines ou 
chaque caractére occupe 2 octets ou 16 bits. Ceci est une erreur de terminologie 
répandue. Unicode est un standard pour assigner un nombre à chaque caractére 
dans un des nombreux systémes d'écriture dans le monde, mais ne décrit pas la 
méthode d'encodage. 


Les méthodes d'encodage les plus répandues sont: UTF-8 (est répandue sur Internet 
et les systémes *NIX) et UTF-16LE (est utilisé dans Windows). 


UTF-8 


UTF-8 est l'une des méthodes les plus efficace pour l'encodage des caractéres. Tous 
les symboles Latin sont encodés comme en ASCII, et les symboles aprés la table ASCII 
sont encodés en utilisant quelques octets. 0 est encodé comme avant, donc toutes 
les fonctions C de chaîne standard fonctionnent avec des chaînes UTF-8 comme avec 
tout autre chaîne. 


Voyons comment les symboles de divers langages sont encodés en UTF-8 et de quoi 
ils ont l'air en FAR, en utilisant la page de code 437’ : 


How much? 100€? 


(English) I can eat glass and it doesn't hurt me. 

(Greek) Mnop® va púw ocnacuéva yucAiáà xyopic va náðw tinota. 
(Hungarian) Meg tudom enni az üveget, nem lesz tóle bajom. 
(Icelandic) Ég get etié gler án þess að meióa mig. 
(Polish) Mogę jeść szkło i mi nie szkodzi. 

(Russian) A mory ecTb CTeKJIO, OHO MHe He BPeMMT. 

(Arabic): ,isij. Y lis y gji JSi le yola Lil. 
(Hebrew): °? P TN 8? NTI n^212T 21287 "712^ ‘IN. 

(Chinese) EA NEREMIAASA o 

(Japanese) PHISHSARB“SHET o ENIRE DIE BA © 

(Hindi) E E AM saa HS RIE 


7L'exemple et les traductions ont été pris d'ici: http://www.columbia.edu/-fdc/utf8/ 
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Fig. 5.2: FAR: UTF-8 


Comme vous le voyez, la chaíne en anglais est la méme qu'en ASCII. 


Le hongrois utilise certains symboles Latin et des symboles avec des signes diacri- 
tiques. 


Ces symboles sont encodés en utilisant plusieurs octets, qui sont soulignés en rouge. 
C'est le méme principe avec l'islandais et le polonais. 


Il y a aussi le symbole de l'«Euro » au début, qui est encodé avec 3 octets. 
Les autres systémes d'écritures n'ont de point commun avec Latin. 


Au moins en russe, arabe hébreux et hindi, nous pouvons voir des octets récurrents, 
et ce n'est pas une surprise: tous les symboles d'un systéme d'écriture sont en 
général situés dans la méme table Unicode, donc leur code débute par le máme 
nombre. 


Au début, avant la chaine «How much? », nous voyons 3 octets, qui sont en fait le 
BOM. Le BOM défini le système d'encodage à utiliser. 


UTF-16LE 


De nombreuses fonctions win32 de Windows ont le suffixes -A et -W. Le premier 
type de fonctions fonctionne avec les chaînes normales, l'autre, avec des chaîne 
UTF-16LE (/arge). 


Dans le second cas, chaque symbole est en général stocké dans une valeur 16-bit 
de type short. 


Les symboles Latin dans les chaines UTF-16 dans Hiew ou FAR semblent étre séparés 
avec un octet zéro: 


int wmain() 


1 
$; 


wprintf (L"Hello, world!\n"); 


8Byte Order Mark 
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| Hiew: hw2.exe 


Fig. 5.3: Hiew 


Nous voyons souvent ceci dans les fichiers systéme de Windows NT : 


view ntoskrnl.exe - Far 2.0.1807 x64 Administrator 


Fig. 5.4: Hiew 


Les chaînes avec des caracteres qui occupent exactement 2 octets sont appelées 
«Unicode » dans IDA : 


.data:0040E000 aHelloWorld: 
.data:0040E000 unicode 0, «Hello, world!» 
.data:0040E000 dw 0Ah, 0 


Voici comment une chaine en russe est encodée en UTF-16LE: 
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1 AP=>0200¢  7949(*0929A$B929C 
o e o 6 


Fig. 5.5: Hiew: UTF-16LE 


Ce que nous remarquons facilement, c'est que les symboles sont intercalés par le 
caractére diamant (qui a le code ASCII 4). En effet, les symboles cyrilliques sont 
situés dans le quatriéme plan Unicode. Ainsi, tous les symboles cyrillique en UTF- 
16LE sont situés dans l'intervalle 0x400-0x4FF. 


Retournons à l'exemple avec la chaîne écrite dans de multiple langages. Voici à quoi 
elle ressemble en UTF-16LE. 


B view hw4_UTF16le.txt - Far 3.0.4040 x64 Administrator c El EA 


w much? 100 X? 


EngiI3sh25 E can eat glass and * € do esu": hurt 
Gr e ek) ELO VIO IVV UA O [VIVEN IVIV¡VIVEY |[VIVEV VIVO [Y VLV»V,Y IVV VAV VH 
Voy LV- VVV. 


n 


ian) Meg tudom nni az veget, 


gler Bn mess a 


Mog lə je [eee s z k Beo i m i nie s zk od 
/*  «9»939C9 H5OAOBOL  A9B$59:9; 4-6, >b=b>4 «4-959 -45* 2040054408054. 
#4F4'4 B4'4/414 94DATA #4C4D4 '4D424,4'4 4 H^ G404'4 DO'S JATADALAFAJA. 


Loblé e ahi mt e OR [Au Ro ael MH att. 


<b?CaTGNqsatoc 


1y00/00040405yy0€010-0Y0800]7010001y4£07Pd000-0 [05080 


Fig. 5.6: FAR: UTF-16LE 


Ici nous pouvons aussi voir le BOM au début. Tous les caracteres Latin sont intercalés 
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avec un octet à zéro. 


Certains caractéres avec signe diacritique (hongrois et islandais) sont aussi souli- 
gnés en rouge. 


Base64 


L'encodage base64 est trés répandu dans les cas où vous devez transférer des don- 
nées binaires sous forme de chaîne de texte. 


Pour l'essentiel, cet algorithme encode 3 octets binaires en 4 caractéres imprimables: 
toutes les 26 lettres Latin (à la fois minuscule et majuscule), chiffres, signe plus («+ ») 
et signe slash («/ »), 64 caractères en tout. 


Une particularité des chaines base64 est qu'elles se terminent souvent (mais pas 
toujours) par 1 ou 2 symbole égal («=») pour l'alignement, par exemple: 


AVjbbVSVf cUMu1xvj aMgj NtueRwBbxnyJw8dpGnLW8ZW8aKG3v4YOicuQT-*qEJAp9lAO0uWs- 


WV jbbVSVf cUMulxvj aMgjNtueRwBbxnyJw8dpGnLW8ZW8aKG3v4Y0icuQT-qEJAp9lA0uQ-- 


Le signe égal («=») ne se rencontre jamais au milieu des chaines encodées en 
base64. 


maintenant, un exemple d'encodage manuel. Encodons les octets hexadécimaux 
0x00, 0x11, 0x22, 0x33 en une chaine base64: 


$ echo -n "Xx00Nx11Nx22Nx33" | base64 
ABEiMw-- 


Mettons ces 4 octets au forme binaire, puis regroupons les dans des groupes de 
6-bit: 


00 || 11 || 22 || 33 
00000000000100010010001000110011???????????????? 
LA, | [|E [123 TEM [la le T= | 


Les trois premiers octets (0x00, 0x11, 0x22) peuvent être encodés dans 4 caractères 
base64 ("ABEi"), mais le dernier (0x33) — ne le peut pas, donc il est encodé en 
utilisant deux caractéres ("Mw") et de symbole (“=") de padding est ajouté deux fois 
pour compléter le dernier groupe à 4 caractéres. De ce fait, la longueur de toutes 
les chaines en base64 correctes est toujours divisible par 4. 


Base64 est souvent utilisé lorsque des données binaires doivent étre stockées dans 
du XML. Les clefs PGP "Armored" (i.e., au format texte) et les signatures sont enco- 
dées en utilisant base64. 


Certains essayent d'utiliser base64 pour masquer des chaínes: http://blog.sec-consult. 
com/2016/01/deliberately-hidden-backdoor-account-in.html?. 


9http://archive.is/nDCas 
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Il existe des utilitaires pour rechercher des chaines base64 dans des fichiers binaires 
arbitraires. L'un d'entre eux est base64scanner??. 


Un autre systéme d'encodage qui était trés répandu sur UseNet et FidoNet est l'Uuen- 
coding. Les fichiers binaires sont toujours encodés au format Uuencode dans le ma- 
gazine Phrack. ll offre à peu prés la méme fonctionnalité, mais il est différent de 
base64 dans le sens ou le nom de fichier est aussi stocké dans l'entéte. 


À propos: base64 à un petit frère: base32, alphabet qui a 10 chiffres et 26 caractères 
Latin. Un usage répandu est les adresses onion!!, comme: 
http://3g2upl4pq6kufc4m.onion/. URL ne peut pas avoir de mélange de casse 
de caractéres Latin, donc, c'est apparemment pourquoi les développeurs de Tor ont 
utilisé base32. 


5.4.2 Trouver des chaines dans un binaire 


Actually, the best form of Unix 
documentation is frequently running the 
strings command over a program's object 
code. Using strings, you can get a complete 
list of the program's hard-coded file name, 
environment variables, undocumented 
options, obscure error messages, and so 
forth. 


The Unix-Haters Handbook 


En fait, la meilleure forme de documentation Unix est de lancer la commande strings 
sur le code objet d'un programme. En utilisant strings, vous obtenez une liste com- 
pléte des noms de fichiers codés en dur dans le programme, les variables d'environ- 
nement, les options non documentées, les messages d'erreurs méconnus et ainsi 
de suite. 


L'utilitaire standard UNIX strings est un moyen rapide et facile de voir les chaines 
dans un fichier. Par exemple, voici quelques chaínes du fichier exécutable sshd 
d'OpenSSH 7.2: 


0123 

0123456789 
0123456789abcdefABCDEF. :/ 
%02x 


.100s, line %lu: Bad permitopen specification <%.100s> 
.100s, line %lu: invalid criteria 
.100s, line %lu: invalid tun device 


oe ge ge - 


.200s/.ssh/environment 


oe - 


2886173b9c9b6fdbdeda7a247cd636db38deaa.debug 
$2a$06$r3.juUaHZDlIbQa02dS9FuYxL1W9M81R1TC92PoSNmzvpEqLkLGrK 


l0https://github.com/DennisYurichev/base64scanner 
Hhttps://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames 
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3des -cbc 

Bind to port %s on %s. 
Bind to port %s on %s failed: %.200s. 
/bin/login 

/bin/sh 

/bin/sh /etc/ssh/sshrc 
D$4PQWR1 

D$4PUj 

D$4PV 

D$4PVj 

D$4PW 

D$4PWj 

D$4X 

D$4XZj 

D$4Y 


diffie-hellman-group-exchange-shal 
diffie-hellman-group-exchange-sha256 
digests 

D$iPV 

direct-streamlocal 
direct-streamlocal@openssh. com 


FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E0884A6... 


Il y a des options, des messages d'erreur, des chemins de fichier, des modules et des 
fonctions importés dynamiquement, ainsi que d'autres chaînes étranges (clefs?). Il y 
a aussi du bruit illisible—le code x86 à parfois des fragments constitués de caractères 
ASCII imprimables, jusqu'à 8 caractéres. 


Bien sür, OpenSSH est un programme open-source. Mais regarder les chaines lisibles 
dans un binaire inconnu est souvent une premiére étape d'analyse. 


grep peut aussi étre utilisé. 


Hiew a la méme capacité (Alt-F6), ainsi que ProcessMonitor de Sysinternals. 


5.4.3 Messages d'erreur/de débogage 


Les messages de débogage sont trés utiles s'il sont présents. Dans un certain sens, 
les messages de débogage rapportent ce qui est en train de se passer dans le pro- 
gramme. Souvent, ce sont des fonctions printf()-like, qui écrivent des fichiers de 
log, ou parfois elles n'écrivent rien du tout mais les appels sont toujours présents 
puisque le build n'est pas un de débogage mais de release. 


Si des variables locales ou globales sont affichées dans les messages, ca peut étre 
aussi utile, puisqu'il est possible d'obtenir au moins le nom de la variable. Par exemple, 
une telle fonction dans Oracle RDBMS est ksdwrt(). 
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Des chaines de texte significatives sont souvent utiles. Le dés-assembleur IDA peut 
montrer depuis quelles fonctions et depuis quel endroit cette chaîne particulière est 
utilisée. Des cas dróles arrivent parfois??. 


Le message d'erreur peut aussi nous aider. Dans Oracle RDBMS, les erreurs sont 
rapportées en utilisant un groupe de fonctions. 
Vous pouvez en lire plus ici: blog.yurichev.com. 


Il est possible de trouver rapidement quelle fonction signale une erreur et dans 
quelles conditions. 


À propos, ceci est souvent la raison pour laquelle les systémes de protection contre 
la copie utilisent des messages d'erreur inintelligibles ou juste des numéros d'erreur. 
Personne n'est content lorsque le copieur de logiciel comprend comment fonctionne 
la protection contre la copie seulement en lisant les messages d'erreur. 


Un exemple de messages d'erreur chiffrés se trouve ici: 8.8.2 on page 1091. 


5.4.4 Chaînes magiques suspectes 


Certaines chaines magique sont d'habitude utilisées dans les porte dérobées semblent 
vraiment suspectes. 


Par exemple, il y avait une porte dérobée dans le routeur personnel TP-Link WR740?3. 
La porte dérobée était activée en utilisant l'URL suivante: 
http://192.168.0.1/userRpmNatDebugRpm26525557/start art.html. 


En effet, la chaine «userRpmNatDebugRpm26525557 » est présente dans le firm- 
ware. 


Cette chaine n'était pas googlable jusqu'à la large révélation d'information concer- 
nant la porte dérobée. 


Vous ne trouverez ceci dans aucun RFCH, 


Vous ne trouverez pas d'algorithme informatique qui utilise une séquence d'octets 
aussi étrange. 


Et elle ne ressemble pas à une erreur ou un message de débogage. 


Donc, c'est une bonne idée d'inspecter l'utilisation de ce genre de chaînes bizarres. 


Parfois, de telles chaines sont encodées en utilisant base64. 
Donc, c'est une bonne idée de toutes les décoder et de les inspecter visuellement, 
méme un coup d'œil doit suffire. 


Plus précisément, cette méthode de cacher des accés non documentés est appelée 
«sécurité par l'obscurité ». 


12blog.yurichev.com 
Bhttp://sekurak.pl/tp-link-httptftp-backdoor/ 
14Request for Comments 
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5.5 Appels à assert() 


Parfois, la présence de la macro assert() est aussi utile: En général, cette macro 
laisse le nom du fichier source, le numéro de ligne et une condition dans le code. 


L'information la plus utile est contenue dans la condition d'assert, nous pouvons en 
déduire les noms de variables ou les noms de champ de la structure. Les autres 
informations utiles sont les noms de fichier—nous pouvons essayer d'en déduire le 
type de code dont il s'agit ici. II est aussi possible de reconnaitre les bibliothèques 
open-source connues d'aprés les noms de fichier. 


Listing 5.2 : Exemple d'appels à assert() informatifs 


.text:107D4B29 mov dx, [ecx+42h] 

.text:107D4B2D cmp edx, 1 

.text:107D4B30 jz short loc 107D4B4A 

.text:107D4B32 push 1ECh 

.text:107D4B37 push offset aWrite c ; "write.c" 

.text:107D4B3C push offset aTdTd planarcon ; 
"td->td planarconfig == PLANARCONFIG CON"... 

.text:107D4B41 call ds: assert 


.text:107D52CA mov edx, [ebp-4] 

.text:107D52CD and edx, 3 

.text:107D52D0 test edx, edx 

.text:107D52D2 jz short loc 107D52E9 

.text:107D52D4 push 58h 

.text:107D52D6 push offset aDumpmode c ; "dumpmode.c" 
.text:107D52DB push offset aN30 ; "(n & 3) == 0" 
.text:107D52E0 call ds: assert 


.text:107D6759 mov cx, [eax+6] 

.text:107D675D cmp ecx, OCh 

.text:107D6760 jle short loc 107D677A 

.text:107D6762 push 2D8h 

.text:107D6767 push offset aLzw c ON LZWe C" 

.text:107D676C push offset aSpLzw nbitsBit ; “sp->lzw_nbits <= BITS MAX" 
.text:107D6771 call ds: assert 


Il est recommandé de «googler» à la fois les conditions et les noms de fichier, qui 
peuvent nous conduire à une bibliothéque open-source. Par exemple, si nous «goo- 
glons » «sp->Izw_nbits <= BITS MAX», cela va comme prévu nous donner du code 
open-source relatif à la compression LZW. 


5.6 Constantes 


Les humains, programmeurs inclus, utilisent souvent des nombres ronds, comme 10, 
100, 1000, dans la vie courante comme dans le code. 
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Le rétro ingénieur pratiquant connaít en général bien leur représentation décimale: 
10=0xA, 100=0x64, 1000=0x3E8, 10000=0x2710. 


Les constantes OxAAAAAAAA (0b10101010101010101010101010101010) et 
0x55555555 (0b01010101010101010101010101010101) sont aussi répandues—elles 
sont composées d'alternance de bits. 


Cela peut aider à distinguer un signal d'un signal dans lequel tous les bits sont à 
1 (0b1111 ...) ou à O (0b0000 ...). Par exemple, la constante 0x55AA est utilisée 
au moins dans le secteur de boot, MBR!°, et dans la ROM de cartes d'extention de 
compatible IBM. 


Certains algorithmes, particulièrement ceux de chiffrement, utilisent des constantes 
distinctes, qui sont faciles à trouver dans le code en utilisant IDA. 


Par exemple, l'algorithme MD5 initialise ses propres variables internes comme ceci: 


var int hO := 0x67452301 
var int hl := OxEFCDAB89 
var int h2 := 0x98BADCFE 
var int h3 := 0x10325476 


Si vous trouvez ces quatre constantes utilisées à la suite dans du code, il est trés 
probable que cette fonction soit relatives à MD5. 


Un autre exemple sont les algorithmes CRC16/CRC32, ces algorithmes de calcul uti- 
lisent souvent des tables pré-calculées comme celle-ci: 


Listing 5.3 : linux/lib/crc16.c 


/** CRC table for the CRC-16. The poly is 0x8005 (x^l6 + x^15 + x^2 + 1) */ 
ul6 const crcl6 table[256] = { 
0x0000, OxCOC1, OxC181, 0x0140, 0xC301, 0x03CO, 0x0280, 0xC241, 
0xC601, 0x06CO, 0x0780, OxC741, 0x0500, OxC5C1, OxC481, 0x0440, 
OxCCO1, OxOCCO, OxOD80, OxCD41, OxOFOO, OXCFC1, OxCE81, 0x0E40, 


Voir aussi la table pré-calculée pour CRC32: 3.8 on page 615. 


Dans les algorithmes CRC sans table, des polynómes bien connus sont utilisés, par 
exemple OxEDB88320 pour CRC32. 


5.6.1 Nombres magiques 


De nombreux formats de fichier définissent un entéte standard ou un nombre(s) 
magique est utilisé, unique ou méme plusieurs. 


Par exemple, tous les exécutables Win32 et MS-DOS débutent par ces deux carac- 
tères «MZ »16, 


Au début d'un fichier MIDI, la signature «MThd » doit étre présente. Si nous avons un 
programme qui utilise des fichiers MIDI pour quelque chose, il est trés probable qu'il 
doit vérifier la validité du fichier en testant au moins les 4 premiers octets. 


15Master Boot Record 
16Wikipédia 
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Ca peut étre fait comme ceci: (buf pointe sur le début du fichier chargé en mémoire) 


cmp [buf], 0x6468544D ; "MThd" 
jnz error not a MIDI file 


...0u en appelant une fonction pour comparer des blocs de mémoire comme memcmp ( ) 
ou tout autre code équivalent jusqu'à une instruction CMPSB (.1.6 on page 1338). 


Lorsque vous trouvez un tel point, vous pouvez déjà dire que le chargement du 
fichier MIDI commence, ainsi, vous pouvez voir l'endroit oü se trouve le buffer avec 
le contenu du fichier MIDI, ce qui est utilisé dans le buffer et comment. 


Dates 


Souvent, on peut rencontrer des nombres comme 0x19870116, qui ressemble clai- 
rement à une date (année 1987, ler mois (janvier), 16ème jour). Ca peut être la 
date de naissance de quelqu'un (un programmeur, une de ses relations, un enfant), 
ou une autre date importante. La date peut aussi étre écrite dans l'ordre inverse, 
comme 0x16011987. Les dates au format américain sont aussi courante, comme 
0x01161987. 


Un exemple célébre est 0x19540119 (nombre magique utilisé dans la structure du 
super-bloc UFS2), qui est la date de naissance de Marshall Kirk McKusick, éminent 
contributeur FreeBSD. 


Stuxnet utilise le nombre "19790509" (pas comme un nombre 32-bit, mais comme 
une chaîne, toutefois), et ca a conduit à spéculer que le malware était relié à Israël”. 


Aussi, des nombres comme ceux-ci sont trés répandus dans dans le chiffrement 
niveau amateur, par exemple, extrait de la fonction secréte des entrailles du dongle 
HASP3!? : 


void xor pwd(void) 


1 
int i; 
pwd*=0x09071966; 
for (i=0;i<8;i++) 
{ 
al_buf[il= pwd € 7; pwd = pwd >> 3; 
} 
}; 
void emulate func2(unsigned short seed) 
1 
int i, j; 
for(i=0;i<8;i++) 
1 
ch[i] = 0; 


for (j=0;j<8; j++) 


17C'est la date d'exécution de Habib Elghanian, juif persan. 
18https://web.archive.org/web/20160311231616/http: //www.woodmann. com/fravia/bayu3.htm 
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1 
seed *- 0x1989; 
seed += 5; 
ch[i] |= (tab[(seed>>9)60x3f]) << (7-j); 
} 
} 
} 
DHCP 


Ceci s'applique aussi aux protocoles réseaux. Par exemple, les paquets réseau du 
protocole DHCP contiennent un soi-disant nombre magique : 0x63538263. Tout code 
qui génére des paquets DHCP doit contenir quelque part cette constante à insérer 
dans les paquets. Si nous la trouvons dans du code, nous pouvons trouver ce qui 
S'y passe, et pas seulement ca. Tout programme qui peut recevoir des paquet DHCP 
doit vérifier le cookie magique, et le comparer à cette constante. 


Par exemple, prenons le fichier dhcpcore.dll de Windows 7 x64 et cherchons cette 
constante. Et nous la trouvons, deux fois: ll semble que la constante soit utilisée 
dans deux fonctions avec des noms parlants 
DhcpExtractOptionsForValidation() et DhcpExtractFullOptions(): 


Listing 5.4 : dhcpcore.dll (Windows 7 x64) 


| . rdata :000007FF6483CBE8 dword 7FF6483CBE8 dd 63538263h ; DATA XREF: 
DhcpExtractOptionsForValidation+79 
|.rdata:000007FF6483CBEC dword_7FF6483CBEC dd 63538263h ; DATA XREF: 


DhcpExtractFullOptions-97 


Et ici sont les endroits où ces constantes sont accédées: 


Listing 5.5 : dhcpcore.dll (Windows 7 x64) 


.text:000007FF6480875F mov eax, [rsi] 
.text:000007FF64808761 cmp eax, cs:dword 7FF6483CBE8 
.text:000007FF64808767  jnz loc 7FF64817179 

Et: 

Listing 5.6 : dhcpcore.dll (Windows 7 x64) 
.text:000007FF648082C7 mov eax, [r12] 
.text:000007FF648082CB  cmp eax, cs:dword 7FF6483CBEC 
.text:000007FF648082D1 jnz loc 7FF648173AF 


5.6.2 Constantes spécifiques 


Parfois, il y a une constante spécifique pour un certain type de code. Par exemple, je 
me suis plongé une fois dans du code, oü le nombre 12 était rencontré anormalement 
souvent. La taille de nombreux tableaux était 12 ou un multiple de 12 (24, etc.). Il 
s'est avéré que ce code prenait des fichiers audio de 12 canaux en entrée et les 
traitait. 


928 
Et vice versa: par exemple, si un programme fonctionne avec des champs de texte 
qui ont une longueur de 120 octets, il doit y avoir une constante 120 ou 119 quelque 
part dans le code. Si UTF-16 est utilisé, alors 2-120. Si le code fonctionne avec des 
paquets réseau de taille fixe, c'est une bonne idée de chercher cette constante dans 
le code. 


C'est aussi vrai pour le chiffrement amateur (clefs de licence, etc.). Si le bloc chif- 
fré a une taille de » octets, vous pouvez essayer de trouver des occurrences de ce 
nombre à travers le code. Aussi, si vous voyez un morceau de code qui est répété n 
fois dans une boucle durant l'exécution, ceci peut étre une routine de chiffrement/- 
déchiffrement. 


5.6.3 Chercher des constantes 


C'est facile dans IDA : Alt-B or Alt-I. Et pour chercher une constante dans un grand 
nombre de fichiers, ou pour chercher dans des fichiers non exécutables, il y a un 
petit utilitaire appelé binary grep??. 


5.7 Trouver les bonnes instructions 


Si le programme utilise des instructions FPU et qu'il n'y en a que quelques une dans 
le code, on peut essayer de les vérifier chacunes manuellement avec un débogueur. 


Par exemple, nous pouvons étre intéressés de comprendre comment Microsoft Excel 
calcule la formule entrée par l'utilisateur. Par exemple, l'opération de division. 


Si nous chargeons excel.exe (d'Office 2010) version 14.0.4756.1000 dans IDA, fai- 
sons un listing complet et cherchons chaque instruction FDIV (sauf celle qui utilisent 
une constante comme second opérande—évidemment, elles ne nous intéressent 
pas): 


cat EXCEL.lst | grep fdiv | grep -v dbl > EXCEL.fdiv 


... NOUS voyons alors qu'il y en a 144. 


Nous pouvons entrer une chaîne comme =(1/3) dans Excel et vérifier chaque ins- 
truction. 


En vérifiant chaque instruction dans un débogueur ou tracer (on peut vérifier 4 ins- 
tructions à la fois), nous avons de la chance et l'instruction que nous cherchons n'est 
que la 14ème: 


.text:3011E919 DC 33 fdiv qword ptr [ebx] 


PID=13944 | TID=28744|(0) 0x2f64e919 (Excel .exe!BASE+0x11e919) 
EAX-0x02088006 EBX-0x02088018 ECX-0x00000001 EDX-0x00000001 
ESI-0x02088000 EDI-0x00544804 EBP=0x0274FA3C ESP=0x0274F9F8 
EIP-0x2F64E919 

FLAGS-PF IF 

FPU ControlWord-IC RC=NEAR PC=64bits PM UM OM ZM DM IM 


19GitHub 
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FPU StatusWord= 
FPU ST(0): 1.000000 


ST(0) contient le premier argument (1) et le second est dans [EBX]. 


L'instruction aprés FDIV (FSTP) écrit le résultat en mémoire: 


.text:3011E91B DD 1E fstp qword ptr [esi] 


Si nous mettons un point d'arrét dessus, nous voyons le résultat: 


PID=32852 | TID=36488|(0) 0x2f40e91b (Excel.exe!BASE+0x11e91b) 
EAX=0x00598006 EBX=0x00598018 ECX=0x00000001 EDX=0x00000001 
EST=0x00598000 EDI=0x00294804 EBP=0x026CF93C ESP=0x026CF8F8 
EIP=0x2F40E91B 

FLAGS=PF IF 

FPU ControlWord=IC RC=NEAR PC=64bits PM UM OM ZM DM IM 

FPU StatusWord=C1 P 

FPU ST(0): 0.333333 


Pour blaguer, nous pouvons modifier le résultat au vol: 


tracer -l:excel.exe bpx=excel .exe!BASE+0x11E91B,set(st0,666) 


PID=36540 | TID=24056|(0) 0x2f40e91b (Excel.exe!BASE+0x11e91b) 
EAX=0x00680006 EBX=0x00680018 ECX=0x00000001 EDX=0x00000001 
ESI=0x00680000 EDI=0x00395404 EBP=0x0290FD9C ESP=0x0290FD58 
EIP=0x2F40E91B 

FLAGS=PF IF 

FPU ControlWord=IC RC=NEAR PC=64bits PM UM OM ZM DM IM 

FPU StatusWord=C1 P 

FPU ST(0): 0.333333 

Set STO register to 666.000000 


Excel affiche 666 dans la cellule, achevant de nous convaincre que nous avons trouvé 


le bon endroit. 


930 


sayy 


Laste y B Z U~ B ae 


B " Calibri ri ANA = == 


b 
W 
iil 


Clipboard Font Align 
Al - fe | =(123/456) 
B C D 


m 


Pia | ol) ju | bh 


Fig. 5.7: La blague a fonctionné 


Si nous essayons la méme version d’Excel, mais en x64, nous allons y trouver seule- 
ment 12 instructions FDIV, et celle que nous cherchons est la troisiéme. 


tracer.exe -l:excel.exe bpx=excel.exe!BASE+0x1B7FCC, set (st0,666) 


Il semble que le compilateur a remplacé beaucoup d’opérations de division de types 
float et double, par des instructions SSE comme DIVSD (DIVSD est présent 268 fois 


en tout). 


5.8 Patterns de code suspect 


5.8.1 instructions XOR 


Des instructions comme XOR op, op (par exemple, XOR EAX, EAX) sont utilisées 
en général pour mettre la valeur d’un registre a zéro, mais si les opérandes sont 
différentes, l'opération «ou exclusif » est exécutée. 

Cette opération est rare en programmation courante, mais répandu en cryptogra- 
phie, y compris amateur. C'est particulièrement suspect si le second opérande est 
un grand nombre. 


Ceci peut indiquer du chiffrement/déchiffrement, du calcul de somme de contróle, 
etc. 


Une exception a cette observation, qu’il est utile de noter, est le «canari» (1.26.3 
on page 358). Sa génération et sa vérification sont souvent effectuées en utilisant 
des instructions XOR. 
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Ce script awk peut être utilisé pour traité les fichiers listing (.Ist) d'IDA : 


gawk -e '$2=="xor" ( tmp=substr($3, 0, length($3)-1); if (tmp!=$4) if($4!z"^2 
V esp") if ($4!="ebp") { print $1, $2, tmp, ",", $4 } }' filename.lst 


Il est aussi utile de noter que ce type de script peut aussi rapporter du code mal 
désassemblé (5.11.1 on page 944). 


5.8.2 Code assembleur écrit à la main 


Les compilateurs modernes ne générent pas les instructions LOOP et RCL. D'un autre 
CÓté, ces instructions sont trés connues des codeurs qui aiment écrire directement 
en langage d'assemblage. Si vous les rencontrez, on peut dire qu'il est trés probable 
que ce morceau de code ait été écrit à la main. De telles instructions sont marquées 
avec un (M) dans la liste des instructions de cet appendice: .1.6 on page 1330. 


De méme, les prologue/épilogue de fonction sont rares dans de l'assembleur écrit à 
la main. 


Il n'y a généralement pas de systéme fixé pour le passage des arguments aux fonc- 
tions dans du code écrit à la main. 


Exemple du noyau de Windows 2003 (ntoskrnl.exe file) : 


MultiplyTest proc near ; CODE XREF: Get386Stepping 
xor CX, CX 

loc 620555: ; CODE XREF: MultiplyTest+E 
push CX 
call Multiply 
pop CX 
jb short locret 620563 
loop loc 620555 
clc 

locret 620563: ; CODE XREF: MultiplyTest+C 
retn 


MultiplyTest endp 


Multiply proc near ; CODE XREF: MultiplyTest+5 
mov ecx, 81h 
mov eax, 417A000h 
mul ecx 
cmp edx, 2 
stc 
jnz short locret 62057F 
cmp eax, OFE7A000h 
stc 
jnz short locret 62057F 
clc 
locret 62057F: ; CODE XREF: Multiply+10 
; Multiply+18 
retn 


Multiply endp 
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En effet, si nous regardons dans le code source de WRK” v1.2, ce code peut être 
trouvé facilement dans le fichier 
WRK-v1.2\base\ntos\ke\i386\cpu.asm. 


D'aprés l'instruction RCL que j'ai pu trouver dans le fichier ntoskrnl.exe de Windows 
2003 x86 (compilé avec MS Visual C compiler). Elle apparait seulement une fois ici, 
dans la fonction RtlExtendedLargeIntegerDivide() et ca pourrait être un cas de 
code assembleur en ligne. 


5.9 Utilisation de nombres magiques lors du tra- 
cing 


Souvent, notre but principal est de comprendre comment le programme utilise une 
valeur qui a été soit lue d’un fichier ou recue par le réseau. Le tracing manuel d’une 
valeur est souvent une tache laborieuse. Une des techniques les plus simple pour 
ceci (bien que non sûre à 100%) est d'utiliser votre propre nombre magique. 


Ceci ressemble a la tomodensitométrie aux rayons X: un agent de radio-contraste 
est injecté dans le sang du patient, qui est utilisé pour augmenter la visibilité de la 
structure interne du patient aux rayons X. C’est bien connu comment le sang circule 
dans les reins d’humains en bonne santé et si l'agent est dans le sang, il peut étre 
vu facilement en tomographie comment le sang circule et si il y a des calculs ou des 
tumeurs. 


Nous pouvons prendre un nombre 32-bit comme Ox0badf00d, ou la date de nais- 
sance de quelqu'un comme 0x11101979 et écrire ce nombre de 4 octets quelque 
part dans un fichier utilisé par le programme que nous investiguons. 


Puis, en suivant ce programme avec tracer en mode code coverage, avec l'aide de 
grep ou simplement en cherchant dans le fichier texte (résultant de l'investigation), 
nous pouvons facilement voir oü la valeur a été utilisée et comment. 


Exemple de résultats de tracer grepable en mode cc : 


0x150bf66 (_kziaia+0x14), e= 1 [MOV EBX, [EBP+8]] [EBP+8]=0xf59c934 

Ox150bf69 (_kziaia+0x17), e= 1 [MOV EDX, [69AEB08h]] [69AEB08h]-0 

Ox150bf6f (_kziaia+0xld), e= 1 [FS: MOV EAX, [2Ch]] 

0x150bf75 (_kziaia+0x23), e= 1 [MOV ECX, [EAX+EDX*4]] [EAX+EDX*4]=0 2 
& xflac360 


0x150bf78 (_kziaia+0x26), e 


Il 
Pp 


[MOV [EBP-4], ECX] ECX=0xflac360 


Cela peut aussi être utilisé pour des paquets réseau. ll est important que le nombre 
magique soit unique et ne soit pas présent dans le code du programme. 


À part tracer, DosBox (émulateur MS-DOS) en mode heavydebug est capable d'écrire 
de l'information à propos de l'état de tous les registres pour chaque instruction du 
programme exécutée dans un fichier texte?!, donc cette technique peut étre utile 
également pour des programmes DOS. 


2) Windows Research Kernel 
21Voir aussi mon article de blog sur cette fonctionnalité de DosBox: blog.yurichev.com 
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5.10 Boucles 


À chaque fois que votre programme travaille avec des sortes de fichier, ou un buffer 
d'une certaine taille, il doit s'agir d'un sorte de boucle de déchiffrement/traitement 
à l'intérieur du code. 


Ceci est un exemple réel de sortie de l'outil tracer. Il y avait un code qui chargeait 
une sorte de fichier chiffré de 258 octets. Je l'ai lancé dans l'intention d'obtenir le 
nombre d'exécution de chaque instruction (l'outil DBI irait beaucoup mieux de nos 
jours). Et j'ai rapidement trouvé un morceau de code qui était exécuté 259/258 fois: 


0x45a6b5 e= 1 [FS: MOV [0], EAX] EAX=0x218fb08 

0x45a6bb e= 1 [MOV [EBP-254h], ECX] ECX=0x218fbd8 
0x45a6c1 e= 1 [MOV EAX, [EBP-254h]] [EBP-254h]=0x218fbd8 
0x45a6c7 e= 1 [CMP [EAX+14h], 0] [EAX+14h]=0x102 
0x45a6cb e= 1 [JZ 45A9F2h] ZF=false 

0x45a6d1 e= 1 [MOV [EBP-0Dh], 1] 

0x45a6d5 e= 1 [XOR ECX, ECX] ECX=0x218fbd8 

0x45a6d7 e= 1 [MOV [EBP-14h], CX] CX=0 

0x45a6db e= 1 [MOV [EBP-18h], 0] 

0x45a6e2 e= 1 [JMP 45A6EDh] 


0x45a6e4 e= 258 [MOV EDX, [EBP-18h]] [EBP-18h]=0..5 (248 items skipped) 07 
S Xfd..0x101 

0x45a6e7 e- 258 [ADD EDX, 1] EDX=0..5 (248 items skipped) Oxfd..0x101 

0x45a6ea e= 258 [MOV [EBP-18h], EDX] EDX=1..6 (248 items skipped) Oxfe..0v 
y x102 

0x45a6ed e= 259 [MOV EAX, [EBP-254h]] [EBP-254h]=0x218fbd8 

0x45a6f3 e- 259 [MOV ECX, [EBP-18h]] [EBP-18h]=0..5 (249 items skipped) 07 
S xfe..0x102 

0x45a6f6 e= 259 [CMP ECX, [EAX+14h]] ECX=0..5 (249 items skipped) Oxfe..0/ 
V x102 [EAX+14h]=0x102 

0x45a6f9 e= 259 [JNB 45A727h] CF=false, true 

0x45a6fb e= 258 [MOV EDX, [EBP-254h]] [EBP-254h]=0x218fbd8 

0x45a701 e= 258 [MOV EAX, [EDX+10h]] [EDX+10h]=0x21ee4c8 

0x45a704 e= 258 [MOV ECX, [EBP-18h]] [EBP-18h]=0..5 (248 items skipped) 07 
y Xfd..0x101 

0x45a707 e= 258 [ADD ECX, 1] ECX=0..5 (248 items skipped) Oxfd..0x101 

0x45a70a e= 258 [IMUL ECX, ECX, 1Fh] ECX=1..6 (248 items skipped) 0xfe..07 
y x102 

0x45a70d e= 258 [MOV EDX, [EBP-18h]] [EBP-18h]=0..5 (248 items skipped) 07 
S Xfd..0x101 

0x45a710 e= 258 [MOVZX EAX, [EAX+EDX]] [EAX+EDX]=1..6 (156 items skipped) 07 
Y Xf3, 0xf8, Oxf9, Oxfc, Oxfd 

0x45a714 e- 258 [XOR EAX, ECX] EAX=1..6 (156 items skipped) 0xf3, Oxf8, 07 
V Xf9, Oxfc, Oxfd ECX=0x1f, 0x3e, Ox5d, Ox7c, Ox9b (248 items skipped) 7 
S Oxlec2, Oxleel, Ox1f00, Ox1f1f, Ox1f3e 

0x45a716 e- 258 [MOV ECX, [EBP-254h]] [EBP-254h]=0x218fbd8 

0x45a71c e= 258 [MOV EDX, [ECX+10h]] [ECX+10h]=0x21ee4c8 

0x45a71f e= 258 [MOV ECX, [EBP-18h]] [EBP-18h]=0..5 (248 items skipped) 07 
S xfd..0x101 

0x45a722 e= 258 [MOV [EDX+ECX], AL] AL=0..5 (77 items skipped) 0xe2, Oxee, 2 
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V Oxef, 0xf7, Oxfc 


0x45a725 
0x45a727 
0x45a729 
0x45a72f 
0x45a734 
0x45a736 
0x45a73b 


e= 
e= 
e= 
e= 
e= 
e= 
e= 


258 
1 


PRP P 


[JMP 45A6E4h] 

[PUSH 5] 

[MOV ECX, [EBP-254h]] [EBP-254h]=0x218fbd8 
[CALL 45B500h] 

[MOV ECX, EAX] EAX=0x218fbd8 

[CALL 45B710h] 

[CMP EAX, 5] EAX=5 


Il s'avére qu'il s'agit de la boucle de déchiffrement. 


5.10.1 Quelques schémas de fichier binaire 


Tous les exemples ici ont été préparé sur Windows, avec la page de code 437 ac- 
tivéedans la console. L'intérieur des fichiers binaires peut avoir l'air différent avec 
une autre page de code. 
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Tableaux 


Parfois, nous pouvons clairement localiser visuellement un tableau de valeurs 16/32/64- 
bit, dans un éditeur hexadécimal. 


Voici un exemple de tableau de valeurs 16-bit. Nous voyons que le premier octet 
d'une paire est 7 ou 8, et que le second semble aléatoire: 


Fig. 5.8: FAR: tableau de valeurs 16-bit 


J'ai utilisé un fichier contenant un signal 12-canaux numérisé en utilisant 16-bit 
ADC?2. 


22 Analog-to-Digital Converter 
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Et voici un exemple de code MIPS trés typique. 


Comme nous pouvons nous en souvenir, chaque instruction MIPS (et aussi ARM en 
mode ARM ou ARM64) a une taille de 32 bits (ou 4 octets), donc un tel code est un 
tableau de valeurs 32-bit. 


En regardant cette copie d'écran, nous voyons des sortes de schémas. 


Les lignes rouge verticales ont été ajoutées pour la clarté: 


00005000 
00005000: | = B«B ng CM!ÉaB 
00005010: L BB!uls B4$Eb 
00005020: L aB«xBC B INe pa 
00005030: L a d'o laa dn 
00005040: L H CM!ÉaB BB«!ulg 
00005050: i Bb aB«XBC 
00005060: 
00005070: 
00005080: 
00005090: 
000050A0: 
000050B0: 
000050C0: 
000050D0: 
000050E0: 
000050F0: ! i 
00005100: 


x] 


El B|« bm 
peg J'g ag 
g«!ulg« bm 
paa J'o Je 
3 ing cM!ÉaB 
+ BJA cma Jn 
g dro Nan. 
CM!EaBe BY 
twlapar| cma Jn 
00005110: paa dso laa 
00005120: CM! ÉaB!ulg 
00005130: ! Daa] Cma 218 pa 
00005140: Jeo 125 dn 
00005150: LME B$BeB!B AF 
00005160: bm{" Y8H8|B/IB) 
00005170: bM!ÉaB!B a Bx 
00005180: 51 Q B$8 no io DA 
00005190: 25 L QE c$8 hu- ja 
00005140: 04 ! B A$'E a f<E BF 
000051B0: 02 | B n0 nO $8 X M 
1G10ba1 2ESIBIK 3CDYÉ ReLoad. ‘Strind Direct:Table PE EE 


[M 


w 


— 
[2] 


E 
o m Lo 
3 [09] 


a 
B 
D 
B 
a 
! 
B 
Bm 


E 


aa -— 


© © E) a 


Fig. 5.9: Hiew: code MIPS très typique 


Il y a un autre exemple de tel schéma ici dans le livre: 9.5 on page 1255. 
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Fichiers clairsemés 


Ceci est un fichier clairsemé avec des données éparpillées dans un fichier presque 
vide. Chaque caractére espace est en fait l'octet zéro (qui rend comme un espace). 
Ceci est un fichier pour programmer des FPGA (Altera Stratix GX device). Bien sûr, 
de tels fichiers peuvent étre compressés facilement, mais des formats comme celui- 
ci sont trés populaire dans les logiciels scientifiques et d'ingénierie, oü l'efficience 
des accés est importante, tandis que la compacité ne l'est pas. 


Fig. 5.10: FAR: Fichier clairsemé 
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Fichiers compressés 


Ce fichier est juste une archive compressée. Il a une entropie relativement haute et 
visuellement, il à l'air chaotique. Ceci est ce à quoi ressemble les fichiers compressés 
et/ou chiffrés. 


Fig. 5.11: FAR: Fichier compressé 
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CDFS?? 


Les fichiers d'installation d'un OS sont en général distribués sous forme de fichiers 
ISO, qui sont des copies de disques CD/DVD. Le systeme de fichiers utilisé est appe- 
lé CDFS, ce que vous voyez ici sont des noms de fichiers mixés avec des données 
additionnelles. Ceci peut-étre la taille des fichiers, des pointeurs sur d'autres réper- 
toires, des attributs de fichier, etc. C'est l'aspect typique de ce à quoi ressemble un 
systeme de fichiers en interne. 


Fig. 5.12: FAR: Fichier ISO: CD?^ d'installation d'Ubuntu 15 


?3Compact Disc File System 
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Code exécutable x86 32-bit 


Voici l'allure de code exécutable x86 32-bit. II n'a pas une grande entropie, car cer- 
tains octets reviennent plus souvent que d'autres. 


Fig. 5.13: FAR: Code exécutable x86 32-bit 
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Fichiers graphique BMP 


Les fichiers BMP ne sont pas compressés, donc chaque octet (ou groupe d'octet) 
représente chaque pixel. J'ai trouvé cette image quelque part dans mon installation 


de Windows 8.1: 


Microsoft* 


E 


Fig. 5.14: Image exemple 


Vous voyez que cette image a des pixels qui ne doivent pas pouvoir étre compressés 
beaucoup (autour du centre), mais il y a de longues lignes monochromes au haut 
et en bas. En effet, de telles lignes ressemblent à des lignes lorsque l'on regarde le 
fichier: 


A? > >? > > > 000000000000 


.............c rece e -Y 


de * a 


Fig. 5.15: Fragment de fichier BMP 


5.10.2 Comparer des «snapshots » mémoire 


La technique consistant à comparer directement deux états mémoire afin de voir les 
changements était souvent utilisée pour tricher avec les jeux sur ordinateurs 8-bit 
et pour modifier le fichiers des «meilleurs scores ». 


Par exemple, si vous avez chargé un jeu sur un ordinateur 8-bit (il n'y a pas beaucoup 
de mémoire dedans, mais le jeu utilise en général encore moins de mémoire), et 
que vous savez que vous avez maintenant, disons, 100 balles, vous pouvez faire un 
«snapshot » de toute la mémoire et le sauver quelque part. Puis, vous tirez une fois, 
le compteur de balles descend à 99, faites un second «snapshot » et puis comparer 
les deux: il doit y avoir quelque part un octet qui était à 100 au début, et qui est 
maintenant à 99. 


En considérant le fait que ces jeux 8-bit étaient souvent écrits en langage d'assem- 
blage et que de telles variables étaient globales, on peut déterminer avec certitude 
quelle adresse en mémoire contenait le compteur de balles. Si vous cherchiez toutes 
les références à cette adresse dans le code du jeu désassemblé, il n'était pas tres 
difficile de trouver un morceau de code décrémentant le compteur de balles, puis 
d'y écrire une, ou plusieurs, instruction NOP, et d'avoir un jeu avec toujours 100 
balles. Les jeux sur ces ordinateurs 8-bit étaient en général chargés à une adresse 
constante, aussi, il n'y avait pas beaucoup de versions ce chaque jeu (souvent, une 
seule version était répandue pour un long moment), donc les joueurs enthousiastes 
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savaient à quelles adresses se trouvaient les octets qui devaient étre modifiés (en 
utilisant l'instruction BASIC POKE) pour le bidouiller. Ceci à conduit à des listes de 
«cheat » qui contenaient les instructions POKE publiées dans des magazines relatifs 
aux jeux 8-bit. 


De méme, il est facile de modifier le fichier des «meilleurs scores», ceci ne fonc- 
tionne pas seulement avec des jeux 8-bit. Notez votre score et sauvez le fichier 
quelque part. Lorsque le décompte des «meilleurs scores » devient différent, com- 
parez juste les deux fichiers, ca peut méme être fait avec l'utilitaire DOS FC?? (les 
fichiers des «meilleurs scores » sont souvent au format binaire). 


Il y aura un endroit oü quelques octets seront différents et il est facile de voir lesquels 
contiennent le score. Toutefois, les développeurs de jeux étaient conscient de ces 
trucs et pouvaient protéger le programme contre ca. 


Exemple quelque peu similaire dans ce livre: 9.3 on page 1241. 


Une histoire vraie de 1999 


C'était un temps de l'engouement pour la messagerie ICQ, au moins dans les pays 
de l'ex-URSS. Cette messagerie avait une particularité — certains utilisateurs ne vou- 
laient pas partager leur état en ligne avec tout le monde. Et vous deviez demander 
une autorisation à cet utilisateur. Il pouvait vous autoriser à voir son état, ou pas. 


Voici ce que j'ai fait: 
* Ajouté un utilisateur. 


* Un utiliseur est apparu dans la liste de contact, dans la section "attente d'au- 
torisation". 


* Fermé ICQ. 

* Sauvegardé la base de données ICQ. 

* Ouvert à nouveau ICQ. 

* L'utilisateur m'a autorisé. 

* Refermé ICQ et comparé les deux base de données. 


Il s'est avéré que: les deux bases de données ne différaient que d'un octet. Dans 
la première version: RESU\x03, dans la seconde: RESU\x02. ("RESU", signifie proba- 
blement "USER", i.e., un entéte d'une structure oü toutes les informations à propos 
d'un utilisateur étaient stockées.) Cela signifie que l'information sur l'autorisation 
n'était pas stockée sur le serveur, mais sur le client. Vraisemblablement, la valeur 
2/3 reflétait l'état de l'«autorisation ». 


Registres de Windows 


Il est aussi possible de comparer les registres de Windows avant et aprés l'installation 
d'un programme. 


25Utilitaire MS-DOS pour comparer des fichiers binaires. 
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C'est une méthode courante que de trouver quels sont les éléments des registres 
utilisés par le programme. Peut-étre que ceci est la raison pour laquelle le shareware 
de «nettoyage des registres windows » est si apprécié. 


Á propos, voici comment sauver les registres de Windows dans des fichiers texte: 


reg export HKLM HKLM. reg 
reg export HKCU HKCU. reg 
reg export HKCR HKCR. reg 
reg export HKU HKU. reg 

reg export HKCC HKCC. reg 


lls peuvent être comparés en utilisant diff... 


Logiciels d'ingénierie, de CAO, etc. 


Si un logiciel utilise des fichiers propriétaires, vous pouvez aussi les examiner. Sau- 
vez un fichier. Puis, ajouter un point ou une ligne ou une autre primitive. Sauvez le 
fichier, comparez. Ou déplacez un point, sauvez le fichier, comparez. 


Comparateur à clignotement 


La comparaison de fichiers ou d'images mémoire nous rappelle le comparateur à 
clignotement ?* : Un dispositif utilisé autrefois par les astronomes pour trouver les 
objets célestes changeant de position. 


Les comparateurs à clignotement permettent d'alterner rapidement entre deux pho- 
tographies prisent à des moments différents, de facon à faire apparaître les diffé- 
rences visuellement. 


À propos, Pluton a été découverte avec un comparateur à clignotement en 1930. 


5.11 Détection de l'ISA 


Souvent, vous avez à faire à un binaire avec un ISA inconnu. Peut-étre que la maniére 
la plus facile de détecter l'ISA est d'en essayer plusieurs dans IDA, objdump ou un 
autre désassembleur. 


Pour réussir ceci, il faut comprendre la différence entre du code incorrectement et 
celui correctement désassemblé. 


5.11.1 Code mal désassemblé 


Un rétro ingénieur pratiquant a souvent à faire avec du code mal désassemblé. 


26https://en.wikipedia.org/wiki/Blink comparator 
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Désassemblage depuis une adresse de début incorrecte (x86) 


Contrairement à ARM et MIPS (où toute instruction a une longueur de 2 ou 4 octets), 
les instructions x86 ont une taille variable, donc tout désassembleur démarrant à 
une mauvaise adresse qui se trouve au milieu d'une instruction x86 pourra produire 
un résultat incorrect. 


À titre d'exemple: 


add [ebp-31F7Bh], cl 
dec dword ptr [ecx-3277Bh] 
dec dword ptr [ebp-2CF7Bh] 
inc dword ptr [ebx-7A76F33Ch] 
fdiv st(4), st 
db OFFh 
dec dword ptr [ecx-21F7Bh] 
dec dword ptr [ecx-22373h] 
dec dword ptr [ecx-2276Bh] 
dec dword ptr [ecx-22B63h] 
dec dword ptr [ecx-22F4Bh] 
dec dword ptr [ecx-23343h] 
jmp dword ptr [esi-74h] 
xchg eax, ebp 

clc 

std 
db OFFh 
db OFFh 
mov word ptr [ebp-214h], cs ; «- le désassembleur a finalement trouvé la 

bonne voie ici 

ov word ptr [ebp-238h], ds 
mov word ptr [ebp-23Ch], es 
mov word ptr [ebp-240h], fs 
mov word ptr [ebp-244h], gs 
pushf 
pop dword ptr [ebp-210h] 
mov eax, [ebp+4] 
mov [ebp-218h], eax 
lea eax, [ebp+4] 
mov [ebp-20Ch], eax 
mov dword ptr [ebp-2D0h], 10001h 
mov eax, [eax-4] 
mov [ebp-21Ch], eax 
mov eax, [ebp+0Ch] 
mov [ebp-320h], eax 
mov eax, [ebp+10h] 
mov [ebp-31Ch], eax 
mov eax, [ebp+4] 
mov [ebp-314h], eax 

call ds:IsDebuggerPresent 
mov edi, eax 
lea eax, [ebp-328h] 
push eax 

call sub 407663 
pop ecx 


test eax, eax 
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jnz short loc 402D7B 


Il y a des instructions incorrectement désassemblées au début, mais finalement le 
désassembleur revient sur la bonne voie. 


À quoi ressemble du bruit aléatoire désassemblé? 


Des propriétés répandues qui peuvent étre repérées facilement sont: 


* Dispersion d'instructions inhabituellement grande. Les instructions x86 les 
plus fréquentes sont PUSH, MOV, CALL, mais ici nous voyons des instructions de 
tous les groupes d'instructions: FPU, IN/OUT, instructions systémes et rares. 


Valeurs grandes et aléatoires, d'offsets et immédiates. 


Sauts ayant des offsets incorrects, sautant au milieu d'autres instructions 


Listing 5.7 : bruit aléatoire (x86) 


mov bl, OCh 

mov ecx, 0D38558Dh 
mov eax, ds:2C869A86h 
db 67h 

mov dl, OCCh 

insb 

movsb 

push eax 

xor [edx-53h], ah 
fcom qword ptr [edi-45A0EF72h] 
pop esp 

pop SS 

in eax, dx 

dec ebx 

push esp 

lds esp, [esi-41h] 
retf 

rct dword ptr [eax], cl 
mov cl, 9Ch 

mov ch, ODFh 

push CS 

insb 

mov esi, 0D9C65E4Dh 
imul ebp, [ecx], 66h 
pushf 

sal dword ptr [ebp-64h], cl 
sub eax, 0AC433D64h 
out 8Ch, eax 

pop SS 

sbb [eax], ebx 

aas 


xchg cl, [ebx+ebx*4+14B31Eh] 
jecxz short near ptr loc 5841 
xor al, 0C6h 

inc edx 
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db 36h 

pusha 

stosb 

test [ebx], ebx 
sub al, 0D3h ; 'L' 
pop eax 

stosb 


loc 58: ; CODE XREF: seg000:0000004A 


test [esi], eax 

inc ebp 

das 

db 64h 

pop ecx 

das 

hlt 

pop edx 

out OBOh, al 

lodsb 

push ebx 

cdq 

out dx, al 

sub al, OAh 

sti 

outsd 

add dword ptr [edx], 96FCBE4Bh 
and eax, 0E537EE4Fh 
inc esp 

stosd 

cdq 

push ecx 

in al, OCBh 

mov ds:0D114C45Ch, al 
mov esi, 659D1985h 


Listing 5.8 : bruit aléatoire (x86-64) 


lea esi, [rax+rdx*4+43558D29h] 
loc AF3: ; CODE XREF: seg000:0000000000000B46 
rct byte ptr [rsi+rax*8+29BB423Ah], 1 
lea ecx, cs:QFFFFFFFFB2A6780Fh 
mov al, 96h 
mov ah, OCEh 
push rsp 
lods byte ptr [esi] 
db 2Fh ; / 
pop rsp 
db 64h 


retf 0E993h 
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cmp ah, [rax+4Ah] 

movzx rsi, dword ptr [rbp-25h] 
push 4Ah 

movzx rdi, dword ptr [rdi+rdx*8] 
db 9Ah 

rcr byte ptr [rax+1Dh], cl 
lodsd 

xor [rbp+6CF20173h], edx 
xor [rbp+66F8B593h], edx 
push rbx 

sbb ch, [rbx-0Fh] 

stosd 

int 87h 

db 46h, 4Ch 

out 33h, rax 

xchg eax, ebp 

test ecx, ebp 

movsd 

leave 

push rsp 

db 16h 

xchg eax, esi 

pop rdi 


loc B3D: ; CODE XREF: seg000:0000000000000B5F 
mov ds:93CA685DF98A90F9h, eax 


jnz short near ptr loc AF3+6 
out dx, eax 

cwde 

mov bh, 5Dh ; ‘|: 

movsb 

pop rbp 


Listing 5.9 : bruit aléatoire (ARM (Mode ARM)) 


BLNE  @xFE16A9D8 
BGE 0x1634D0C 

SVCCS  0x450685 

STRNVT R5, [PC],#-0x964 

LDCGE p6, c14, [RO],#0x168 

STCCSL p9, c9, [LR], £0x14C 

CMNHIP PC, R10,LSL#22 

FLDMIADNV LR!, {D4} 

MCR p5, 2, R2,c15,c6, 4 

BLGE  Ox1139558 

BLGT  OxFF9146E4 

STRNEB R5, [R4],40xCA2 

STMNEIB R5, {RO,R4,R6,R7,R9-SP, PC} 
STMIA R8, [RO,R2-R4,R7, R8, R10, SP, LR)^ 
STRB SP, [R8],PC,ROR#18 
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LDCCS p9, c13, [R6,40x1BC] 
LDRGE R8, [R9,#0x66E] 

STRNEB R5, [R8],#-0x8C3 
STCCSL p15, c9, [R7,#-0x84] 
RSBLS LR, R2, R11,ASR LR 
SVCGT  0x9B0362 

SVCGT — 0xA73173 

STMNEDB R11!, {RO,R1,R4-R6,R8,R10,R11, SP} 
STR RO, [R3],4-OxCE4 

LDCGT p15, c8, [R1,#0x2CC] 
LDRCCB R1, [R11], -R7,ROR#30 
BLLT  OxFED9D58C 

BL 0x13E60F4 

LDMVSIB R3!, {R1,R4-R7}* 
USATNE R10, 47, SP,LSL#11 
LDRGEB LR, [R1],#0xE56 

STRPLT R9, [LR],40x567 

LDRLT R11, [R1],#-0x29B 
SVCNV 0x12DB29 

MVNNVS R5, SP,LSL#25 

LDCL p8, c14, [R12,#-0x288] 
STCNEL p2, c6, [R6,#-OxBC]! 
SVCNV — Ox2E5A2F 

BLX 0x1A8C97E 

TEQGE R3, #0x1100000 

STMLSIA R6, {R3,R6,R10,R11, SP} 
BICPLS R12, R2, 40x5800 

BNE 0x7CC408 

TEQGE — R2, R4,LSL#20 

SUBS R1, R11, 40x28C 

BICVS — R3, R12, R7,ASR RO 
LDRMI R7, [LR],R3,LSL#21 
BLMI  Ox1A79234 

STMVCDB R6, (RO0-R3,R6,R7, R10, R11) 
EORMI R12, R6, #0xC5 

MCRRCS pl, OxF, R1,R3,c2 


Listing 5.10 : bruit aléatoire (ARM (Mode Thumb)) 


LSRS R3, R6, #0x12 
LDRH R1, [R7,#0x2C] 
SUBS RO, 40x55 ; 'U' 


ADR R1, loc 3C 

LDR R2, [SP,#0x218] 
CMP R4, 40x86 

SXTB R7, R4 

LDR R4, [R1,#0x4C] 
STR R4, [R4,R2] 

STR RO, [R6,#0x20] 
BGT OxFFFFFF72 


LDRH R7, [R2,#0x34] 
LDRSH RO, [R2,R4] 
LDRB R2, [R7,R2] 
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DCB 0x17 
DCB OxED 


STRB R3, [R1,R1] 
STR R5, [RO,#0x6C] 
LDMIA R3, {RO-R5,R7} 
ASRS R3, R2, #3 


LDR R4, [SP,#0x2C4] 
SVC OxB5 

LDR Ro, [R1,#0x40] 

LDR R5, =0xB2C5CA32 
STMIA R6, {R1-R4,R6} 

LDR R1, [R3,#0x3C] 

STR R1, [R5,#0x60] 

BCC OxFFFFFF70 

LDR R4, [SP,#0x1D4] 
STR R5, [R5,#0x40] 


ORRS R5, R7 


loc_3C ; DATA XREF: ROM:00000006 
B OXFFFFFF98 


Listing 5.11 : bruit aléatoire (MIPS little endian) 


lw $t9, OxCB3($t5) 
sb $t5, 0x3855($t0) 
sltiu $a2, $a0, -0x657A 
ldr $t4, -0x4D99($a2) 
daddi $s0, $sl, 0x50A4 
lw $s7, -0x2353($s4) 
bgtzl $al, 0x17C5C 


.byte 0x17 
.byte OxED 
.byte 0x4B # K 
.byte 0x54 # T 


lwc2 $31, 0x66C5($sp) 
lwu $s1, 0x10D3($a1l) 
ldr $t6, -0x204B($zero) 
lwcl $f30, Ox4DBE($s2) 
daddiu $t1, $s1, Ox6BD9 


lwu $s5, -0x2C64($v1) 
cop0 0x13D642D 

bne $gp, $t4, OxFFFF9EFO 
lh $ra, 0x1819($s1) 

sdl $fp, -0x6474($t8) 
jal 0x78C0050 

ori $v0, $52, OxC634 
blez $gp, OxFFFEA9D4 

swl $t8, -0x2CD4($s2) 


sltiu $al, $k0, 0x685 
sdcl $f15, 0x5964($at) 
sw $s0, -0x19A6($a1) 
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sltiu  $t6, $a3, -0x66AD 
lb $t7, -Ox4F6($t3) 
sd $fp, 0x4B02($a1) 


Il est important de garder à l'esprit que du code de dépaquetage et de déchiffrement 
construit intelligemment (y compris auto-modifiant) peut avoir l'air aléatoire, mais 
s'exécute toujours correctement. 


5.11.2 Code désassemblé correctement 


Chaque ISA a une douzaine d'instructions les plus utilisées, toutes les autres le sont 
beaucoup moins souvent. 


Concernant le x86, il est intéressant de savoir le fait que les instructions d'appel 
de fonctions (PUSH/CALL/ADD) et MOV sont les morceaux de code les plus fréquem- 
ment exécutées dans presque tous les programmes que nous utilisons. Autrement 
dit, le CPU est trés occupé à passer de l'information entre les niveaux d'abstraction, 
OU, on peut dire qu'il est trés occupé à commuter entre ces niveaux. Indépendam- 
ment du type d'ISA. Ceci a un coût de diviser les problèmes entre plusieurs niveaux 
d'abstraction (ainsi les étres humain peuvent travailler plus facilement avec). 


5.12 Autres choses 


5.12.1 Idée générale 


Un rétro-ingénieur doit essayer se se mettre dans la peau d'un programmeur aussi 
souvent que possible. Pour adopter son point de vue et se demander comment il 
aurait résolu des táches d'un cas spécifique. 


5.12.2 Ordre des fonctions dans le code binaire 


Toutes les fonctions situées dans un unique fichier .c ou .cpp sont compilées dans le 
fichier objet (.o) correspondant. Plus tard, l'éditeur de liens mets tous les fichiers dont 
il a besoin ensemble, sans changer l'ordre ni les fonctions. Par conséquent, si vous 
voyez deux ou plus fonctions consécutives, cela signifie qu'elles étaient situées dans 
le méme fichier source (à moins que vous ne soyez en limite de deux fichiers objet, 
bien sür). Ceci signifie que ces fonctions ont quelque chose en commun, qu'elles 
sont des fonctions du méme niveau d'API, de la méme bibliothéque, etc. 


Ceci est une histoire vraie de pratique: il était une fois, alors que je cherchais des 
fonctions relatives à Twofish dans un programme lié à la bibliothéque CryptoPP, en 
particulier des fonctions de chiffrement/déchiffrement. 

J'ai trouvé la fonction Twofish: :Base: :UncheckedSetKey( ) mais pas d'autres. Aprés 
avoir cherché dans le code source twofish.cpp””, il devint clair que toutes les fonc- 
tions étaient situées dans ce module (twofish.cpp). 


27https://github.com/weidail1/cryptopp/blob/b613522794a7633aa2bd81932a98a0b0a51bc04f/ 
twofish.cpp 
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Donc j'ai essayé toutes les fonctions qui suivaient Twofish: :Base: :UncheckedSetKey ( ) — 
comme elles arrivaient, 
une a été Twofish: :Enc: :ProcessAndXorBlock(), 
une autre—Twofish: :Dec: :ProcessAndXorBlock(). 


5.12.3 Fonctions minuscules 


Les fonctions minuscules comme les fonctions vides (1.3 on page 8) ou les fonctions 
qui renvoient juste “true” (1) ou “false” (0) (1.4 on page 10) sont trés communes, 
et presque tous les compilateurs corrects tendent à ne mettre qu'une seule fonction 
de ce genre dans le code de l'exécutable résultant, méme si il y avait plusieurs 
fonctions similaires dans le code source. Donc, à chaque fois que vous voyez une 
fonction minuscule consistant seulement en mov eax, 1 / ret qui est référencée 
(et peut étre appelée) dans plusieurs endroits qui ne semblent pas reliés les uns au 
autres, ceci peut résulter d'une telle optimisation. 


5.12.4 C++ 


Les données RTTI (3.21.1 on page 720)- peuvent étre utiles pour l'identification des 
classes C++. 


5.12.5 Crash délibéré 


Souvent, vous voulez savoir quelle fonction a été exécutée, et laquelle ne l'a pas 
été. Vous pouvez utiliser un débogueur, mais sur des architectures exotiques, il peut 
ne pas en avoir, donc la facon la plus simple est d'y mettre un opcode invalide, ou 
quelque chose comme INT3 (0xCC). Le crash signalera le fait que l'instruction a été 
exécutée. 


Un autre exemple de crash délibéré: 3.23.4 on page 787. 


Chapitre 6 


Spécifique aux OS 


6.1 Méthodes de transmission d'arguments (calling 
conventions) 


6.1.1 cdecl 


Il s'agit de la méthode la plus courante pour passer des arguments à une fonction 
en langage C/C++. 


Aprés que l'appelé ait rendu la main, l'appelant doit ajuster la valeur du pointeur de 
pile (ESP) pour lui redonner la valeur qu'elle avait avant l'appel de l'appelé. 


Listing 6.1 : cdecl 


push arg3 

push arg2 

push argl 

call function 

add esp, 12 ; returns ESP 


6.1.2 stdcall 


Similaire à cdecl, sauf que c'est l'appelé qui doit réinitialise ESP à sa valeur d'origine 
en utilisant l'instruction RET x et non pas RET, 

avec x = nb arguments * sizeof(int)!. Aprés le retour du callee, l'appelant ne 
modifie pas le pointeur de pile. Il ny’ a donc pas d'instruction add esp, x. 


Listing 6.2 : stdcall 


push arg3 
push arg2 
push argl 
call function 


1La taille d'une variable de type int est de 4 octets sur les systémes x86 et de 8 octets sur les systémes 
x64 
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function: 
;... do something ... 
ret 12 


Cette méthode est omniprésente dans les librairies standard win32, mais pas dans 
celles win64 (voir ci-dessous pour win64). 


Prenons par exemple la fonction 1.89 on page 132 et modifions la légérement en 
utilisant la convention stdcall: 


int  stdcall f2 (int a, int b, int c) 
1 


}; 


return a*b+c; 


Le résultat de la compilation sera quasiment identique à celui de 1.90 on page 132, 
mais vous constatez la présence de RET 12 au lieu de RET. L' appelant ne met pas 
à jour SP aprés l'appel. 


Avecla convention stdcall, on peut facilement déduire le nombre d'arguments 
de la fonction appelée à partir de l'instruction RETN n : divisez n par 4. 


Listing 6.3 : MSVC 2010 


_a$ = 8 ; Size = 4 
_b$ = 12 : size = 4 
_c$ = 16 ; size = 4 
 f2012 PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR _a$[ebp] 
imul eax, DWORD PTR _b$[ebp] 
add eax, DWORD PTR c$[ebp] 
pop ebp 
ret 12 
_f2@12 ENDP 
push 3 
push 2 
push 1 
call _f2@12 
push eax 
push OFFSET $5G81369 
call _printf 
add esp, 8 


Fonctions à nombre d'arguments variables 


Les fonctions du style printf() sont un des rares cas de fonctions à nombre d'ar- 
guments variables en C/C++. Elles permettent d'illustrer une différence importante 
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entre les conventions cdecl et stdcall. Partons du principe que le compilateur connait 
le nombre d'arguments utilisés à chaque fois que la fonction printf() est appelée. 


En revanche, la fonction printf () est déjà compilée dans MSVCRT.DLL (si l'on parle 
de Windows) et ne posséde aucune information sur le nombre d'arguments qu'elle 
va recevoir. Elle peut cependant le deviner à partir du contenu du paramétre format. 


Si la convention stdcall était utilisé pour la fonction printf(), elle devrait réajuster 
le pointeur de pile à sa valeur initiale en comptant le nombre d'arguments dans la 
chaîne de format. Cette situation serait dangereuse et pourrait provoquer un crash 
du programme à la moindre faute de frappe du programmeur. La convention stdcall 
n'est donc pas adaptée à ce type de fonction. La convention cdecl est préférable. 


6.1.3 fastcall 


Il s'agit d'un nom générique pour désigner les conventions qui passent une partie des 
paramétres dans des registres et le reste sur la pile. Historiquement, cette méthode 
était plus performante que les conventions cdecl/stdcall - car elle met moins de 
pression sur la pile. Ce n'est cependant probablement plus le cas sur les processeurs 
actuels qui sont beaucoup plus complexes. 


Cette convention n'est pas standardisée. Les compilateurs peuvent donc l'implé- 
menter à leur guise. Prenez une DLL qui en utilise une autre compilée avec une 
interprétation différente de la convention fastcall. Vous avez un cas d'école et des 
problémes en perspective. 


Les compilateurs MSVC et GCC passent les deux premiers arguments dans ECX et 
EDX, et le reste des arguments sur la pile. 


Le pointeur de pile doit étre restauré à sa valeur initiale par l'appelé (comme pour 
la convention stdcall). 


Listing 6.4 : fastcall 


push arg3 

mov edx, arg2 
mov ecx, argl 
call function 


function: 
. do something .. 
ret 4 


Prenons par exemple la fonction 1.89 on page 132 et modifions la légérement en 
utilisant la convention fastcall: 


int _ fastcall f3 (int a, int b, int c) 
1 


}; 


return a*b+c; 


Le résultat de la compilation est le suivant: 
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Listing 6.5 : MSVC 2010 optimisé/ObO 


_c$ = 8 ; size = 4 
@f3@12 PROC 
; a$ = ecx 
; b$ = edx 
mov eax, ecx 
imul eax, edx 
add eax, DWORD PTR _cļ$[esp-4] 
ret 4 


@f3@12 ENDP 


mov edx, 2 

push 3 

lea ecx, DWORD PTR [edx-1] 
call @f3@12 

push eax 

push OFFSET $5G81390 

call _printf 

add esp, 8 


Nous voyons que l'appelé ajuste SP en utilisant l'instruction RETN suivie d'un opé- 
rande. 


Le nombre d'arguments peut, encore une fois, étre facilement déduit. 


GCC regparm 


Il s'agit en quelque sorte d'une évolution de la convention fastcall?. L'option -mregparm 
permet de définir le nombre d'arguments (3 au maximum) qui doivent étre passés 
dans les registres. EAX, EDX et ECX sont alors utilisés. 


Bien entendu si le nombre d'arguments est inférieur à 3, seuls les premiers registres 
sont utilisés. 


C'est l'appelant qui effectue l'ajustement du pointeur de pile. 


Pour un exemple, voire (1.28.1 on page 395). 


Watcom/OpenWatcom 


Dans le cas de ce compilateur, on parle de «register calling convention ». Les 4 pre- 
miers arguments sont passés dans les registres EAX, EDX, EBX et ECX. Les paramétres 
suivant sont passés sur la pile. 


Un suffixe constitué d'un caractére de soulignement est ajouté par le compilateur au 
nom de la fonction afin de les distinguer de celles qui utilisent une autre convention 
d'appel. 


2http://www.ohse.de/uwe/articles/gcc-attributes.html#func-regparm 
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6.1.4 thiscall 


Cette convention passe le pointeur d'objet this à une méthode en C++. 
Le compilateur MSVC, passe généralement le pointeur this dans le registre ECX. 


Le compilateur GCC passe le pointeur this comme le premier argument de la fonc- 
tion. Thus it will be very visible that internally: all function-methods have an extra 
argument. 


Pour un example, voir (3.21.1 on page 699). 


6.1.5 x86-64 
Windows x64 


La méthode utilisée pour passer les arguments aux fonctions en environnement 
Win64 ressemble beaucoup à la convention fastcall. Les 4 premiers arguments 
sont passés dans les registres RCX, RDX, R8 et R9, les arguments suivants sont pas- 
sés sur la pile. L'appelant doit également préparer un espace sur la pile pour 32 oc- 
tets, soit 4 mots de 64 bits, l'appelé pourra y sauvegarder les 4 premiers arguments. 
Les fonctions suffisamment simples peuvent utiliser les paramétres directement de- 
puis les registres. Les fonctions plus complexes doivent sauvegarder les valeurs de 
paramétres afin de les utiliser plus tard. 


L'appelé est aussi responsable de rétablir la valeur du pointeur de pile à la valeur 
qu'il avait avant l'appel de la fonction. 


Cette convention est utilisée dans les DLLs Windows x86-64 (à la place de stdcall en 
win32). 


Exemple: 


#include <stdio.h> 


void fl(int a, int b, int c, int d, int e, int f, int g) 


{ 
printf ("sd %d %d %d %d %d *din", a, b, c, d, e, f, 9); 
}; 
int main() 
{ 
f1(1,2,3,4,5,6,7); 
}; 

Listing 6.6 : MSVC 2012 /0b 
$SG2937 DB '%d %d %d %d %d %d %d', OaH, OOH 
main PROC 

sub rsp, 72 
mov DWORD PTR [rsp+48], 7 
mov DWORD PTR [rsp+40], 6 


mov DWORD PTR [rsp+32], 5 
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mov 
mov 
mov 
mov 
call 


xor 
add 
ret 
ENDP 


3 
[oi] 
fel- 
= 


Oc 0 
Xu 


d$ 


uu m m ug H i 
E 
© 
BR 


f1 PROC 


mov 
mov 
mov 
mov 
sub 


mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 
lea 
call 


add 
ret 
f1 ENDP 


E 
© 
Q 

RNU q 


DWORD PTR [rsp+32], r9d 
DWORD PTR [rsp+24], r8d 
DWORD PTR [rsp+16], edx 
DWORD PTR [rsp+8], ecx 
rsp, 72 


eax, DWORD PTR g$[rsp] 
DWORD PTR [rsp+56], eax 
eax, DWORD PTR f$[rsp] 
DWORD PTR [rsp+48], eax 
eax, DWORD PTR e$[rsp] 
DWORD PTR [rsp+40], eax 
eax, DWORD PTR d$[rsp] 
DWORD PTR [rsp+32], eax 
r9d, DWORD PTR c$[rsp] 
r8d, DWORD PTR b$[rsp] 
edx, DWORD PTR a$[rsp] 
rcx, OFFSET FLAT: $SG2937 
printf 


rsp, 72 
0 


Nous vyons ici clairement que des 7 arguments, 4 sont passés dans les registres et 
les 3 suivants sur la pile. 


Le prologue du code de la fonction f1() sauvegarde les arguments dans le «scratch 


space »—un espace sur la pile précisément prévu a cet effet. 


Le compilateur agit ainsi car il n’est pas certain par avance qu’il disposera de suf- 
fisamment de registres pour toute la fonction en l'absence des 4 utilisés par les 


paramètres. 
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L'appelant est responsable de l'allocation du «scratch space » sur la pile. 


Listing 6.7 : avec optimisation MSVC 2012 /Ob 


$SG2777 DB ‘sd %d %d %d %d %d %d', OaH, OOH 

a$ = 80 

b$ = 88 

c$ = 96 

d$ = 104 

e$ = 112 

f$ = 120 

g$ - 128 

f1 PROC 

$LN3 
sub rsp, 72 
mov eax, DWORD PTR g$[rsp] 
mov DWORD PTR [rsp+56], eax 
mov eax, DWORD PTR f$[rsp] 
mov DWORD PTR [rsp+48], eax 
mov eax, DWORD PTR e$[rsp] 
mov DWORD PTR [rsp+40], eax 
mov DWORD PTR [rsp+32], r9d 
mov rod, r8d 
mov r8d, edx 
mov edx, ecx 
lea rcx, OFFSET FLAT: $SG2777 
call printf 
add rsp, 72 
ret 0 

f1 ENDP 

main PROC 
sub rsp, 72 
mov edx, 2 
mov DWORD PTR [rsp+48], 7 
mov DWORD PTR [rsp+40], 6 
lea r9d, QWORD PTR [rdx+2] 
lea r8d, QWORD PTR [rdx+1] 
lea ecx, QWORD PTR [rdx-1] 
mov DWORD PTR [rsp+32], 5 
call f1 
xor eax, eax 
add rsp, 72 
ret 0 

main ENDP 


L'exemple compilé en branchant les optimisations, sera quasiment identique, si ce 


n'est que le «scratch space » ne sera pas utilisé car inutile. 
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Notez également la maniére dont MSVC 2012 optimise le chargement de certaines 
valeurs litérales dans les registres en utilisant LEA (.1.6 on page 1333). L'instruction 
MOV utiliserait 1 octet de plus (5 au lieu de 4). 


8.2.1 on page 1042 est un autre exemple de cette pratique. 
Windows x64: Passage de this (C/C++) 


Le pointeur this est passé dans le registre RCX, le premier argument de la méthode 
dans RDX, etc. Pour un exemple, voir : 3.21.1 on page 702. 


Linux x64 


Le passage d'arguments par Linux pour x86-64 est quasiment identique à celui de 
Windows, si ce n'est que 6 registres sont utilisés au lieu de 4 (RDI, RSI, RDX, RCX, 
R8, R9) et qu'il n'existe pas de «scratch space ». L'glslinkcalleeappelé conserve la 
possibilité de sauvegarder les registres sur la pile s'il le souhaite ou en a besoin. 


Listing 6.8 : GCC 4.7.3 avec optimisation 


.LC0: 
.String "%d %d %d %d %d %d din" 
fl: 
sub rsp, 40 
mov eax, DWORD PTR [rsp+48] 
mov DWORD PTR [rsp+8], r9d 
mov r9d, ecx 
mov DWORD PTR [rsp], r8d 
mov ecx, esi 
mov r8d, edx 
mov esi, OFFSET FLAT: .LCO 
mov edx, edi 
mov edi, 1 
mov DWORD PTR [rsp+16], eax 
xor eax, eax 
call . printf chk 
add rsp, 40 
ret 
main: 
sub rsp, 24 
mov r9d, 6 
mov r8d, 5 
mov DWORD PTR [rsp], 7 
mov ecx, 4 
mov edx, 3 
mov esi, 2 
mov edi, 1 
call f1 
add rsp, 24 


ret 
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N.B.: Les valeurs sont enregistrées dans la partie basse des registres (e.g., EAX) et 
non pas dans la totalité du registre 64 bits (RAX). Ceci s'explique par le fait que 
l'écriture des 32 bits de poids faible du registre remet automatiquement à zéro les 
32 bits de poids fort. On suppose qu'AMD a pris cette décision afin de simplifier le 
portage du code 32 bits vers l'architecture x86-64. 


6.1.6 Valeur de retour de type float et double 


Dans toutes les conventions, à l'exception de l'environnement Win64, les valeurs de 
type float ou double sont retournées dans le registre FPU ST(0). 


En environnement Win64, les valeurs de type float et double sont respectivement 
retournées dans les 32 bits de poids faible et dans les 64 bits du registre XMMO. 


6.1.7 Modification des arguments 


Il arrive que les programmeurs C/C++ (et ceux d'autres LPs aussi) se demandent ce 
qui se passe s'ils modifient la valeur des arguments dans la fonction appelée. 


La réponse est simple. Les arguments sont stockés sur la pile, et c'est elle qui est 
modifiée. 

Une fois que l'appelé s'achéve, la fonction appelante ne les utilise pas. (Je n'a jamais 
constaté qu'il en aille autrement). 


#include <stdio.h> 


void f(int a, int b) 


{ 

a=a+b; 

printf ("%d\n", a); 
}; 

Listing 6.9 : MSVC 2012 

_a$ = 8 ; size = 4 
_b$ = 12 : size = 4 
f PROC 

push ebp 

mov ebp, esp 

mov eax, DWORD PTR _a$[ebp] 

add eax, DWORD PTR _b$[ebp] 

mov DWORD PTR _a$[ebp], eax 

mov ecx, DWORD PTR _a$[ebp] 

push ecx 

push OFFSET $5G2938 ; '%d', 0aH 

call _printf 

add esp, 8 

pop ebp 

ret 0 


f ENDP 
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Donc, oui, la valeur des arguments peut étre modifiée sans probléme. Sous réserver 
que l'argument ne soit pas une references en C++ (3.21.3 on page 721), et que 
vous ne modifiez pas la valeur qui est référencée par un pointeur, l'effet de votre 
modification ne se propagera pas au dehors de la fonction. 


En théorie, aprés le retour de l'appelé, l'appelant pourrait récupérer l'argument mo- 
difié et l'utiliser à sa guise. Ceci pourrait peut étre se faire dans un programme rédigé 
en assembleur. 


Par exemple, un compilateur C/C++ générera un code comme celui-ci : 


push 456 ; will be b 

push 123 ; will be a 

call f ; f() modifies its first argument 
add esp, 2*4 


Nous pouvons réécrire le code ainsi : 


push 456 ; will be b 

push 123 ; will be a 

call f ; f() modifies its first argument 
pop eax 

add esp, 4 


; EAX=1st argument of f() modified in f() 


Il est difficile d'imaginer pourquoi quelqu'un aurait besoin d'agir ainsi, mais en pra- 
tique c'est possible. Toujours est-il que les langages C/C++ ne permettent pas de 
faire ainsi. 


6.1.8 Recevoir un argument par adresse 


...mieux que cela, il est possible de passer à une fonction l'adresse d'un argument, 
plutót que la valeur de l'argument lui-méme: 


#include <stdio.h> 


// located in some other file 
void modify_a (int *a); 


void f (int a) 
{ 
modify a (&a); 
printf ("%d\n", a); 
}; 


Il est difficile de comprendre ce fonctionnement jusqu'à ce que l'on regarde le code: 


Listing 6.10 : MSVC 2010 optimisé 


$SG2796 DB '*sd', OaH, OOH 


f PROC 
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lea eax, DWORD PTR a$[esp-4] ; just get the address of value in 
local stack 
eax ; and pass it to modify a() 
call modify a 
mov ecx, DWORD PTR _a$[esp] ; reload it from the Local stack 
push ecx ; and pass it to printf() 
push OFFSET $5G2796 ;o'*8d' 
call _printf 
add esp, 12 
ret 0 
f ENDP 


L'argument a est placé sur la pile et l'adresse de cet emplacement de pile est passé 
à une autre fonction. Celle-ci modifie la valeur à l'adresse référencée par le pointeur, 
puis printf() affiche la valeur aprés modification. 


Le lecteur attentif se demandera peut-étre ce qu'il en est avec les conventions d'ap- 
pel qui utilisent les registres pour passer les arguments. 


C'est justement une des utilisations du Shadow Space. 


La valeur en entrée est copiée du registre vers le Shadow Space dans la pile locale, 
puis l'adresse de la pile locale est passée à la fonction appelée: 


Listing 6.11 : MSVC 2012 x64 optimisé 


$SG2994 DB '*d', OaH, OOH 

a$ = 48 

f PROC 
mov DWORD PTR [rsp+8], ecx ; save input value in Shadow Space 
sub rsp, 40 
lea rcx, QWORD PTR a$[rsp] ; get address of value and pass it 


to modify a() 
call modify a 


mov edx, DWORD PTR a$[rsp] ; reload value from Shadow Space and 
pass it to printf() 
lea rcx, OFFSET FLAT:$5G2994 ; '%d' 
call printf 
add rsp, 40 
ret 0 
f ENDP 


Le compilateur GCC lui aussi sauvegarde la valeur sur la pile locale: 


Listing 6.12 : GCC 4.9.1 optimisé x64 


.LC0: 
.String "%d\n" 
fi 
sub rsp, 24 
mov DWORD PTR [rsp+12], edi ; store input value to the local 
ee rdi, [rsp+12] ; take an address of the value and 


pass it to modify a() 
call modify a 
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mov edx, DWORD PTR [rsp+12] ; reload value from the local stack 
and pass it to printf() 

mov esi, OFFSET FLAT: .LCO ; '%d' 

mov edi, 1 

xor eax, eax 

call . printf chk 

add rsp, 24 

ret 


Le compilateur GCC pour ARM64 se comporte de la méme maniére, mais l'espace 
de sauvegarde sur la pile est dénommé Register Save Area : 


Listing 6.13 : GCC 4.9.1 optimisé ARM64 


f: 
stp x29, x30, [sp, -32]! 
add x29, sp, 0 ; Setup FP 
add x1, x29, 32 ; calculate address of variable in 
Register Save Area 
str w0, [x1,-4]! ; store input value there 
mov x0, x1 ; pass address of variable to the 
modify a() 
bl modify a 
ldr wl, [x29,28] ; load value from the variable and pass it 
to printf() 
adrp x0, .LCO ; '*sd' 
add x0, x0, :1012:.LC0 
bl printf ; call printf() 
ldp x29, x30, [sp], 32 
ret 
.LC0: 


.string "%d\n" 


Enfin, nous constatons un usage similaire du Shadow Space ici: 3.17.1 on page 668. 


6.1.9 Probléme des ctypes en Python (devoir à la maison en 
assembleur x86) 


Un module Python ctypes peut appeler des fonctions externes dans des DLLs, .so's, 
etc. Mais la convention d'appel (pour l'environnement 32-bit) doit étre définie expli- 
citement: 


"ctypes" exports the *cdll*, and on Windows *windll* and *oledll* 
objects, for loading dynamic link libraries. 


You load libraries by accessing them as attributes of these objects. 
*cdll* loads libraries which export functions using the standard 
"cdecl" calling convention, while *windll* libraries call functions 
using the "stdcall" calling convention. 


( https://docs.python.org/3/library/ctypes.html )? 


3NDT:Projet de traduction en francais: https://docs.python.org/fr/3/library/ctypes.html 
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En fait, nous pouvons modifier le module ctypes (ou tout autre module d'appel), afin 
qu'il appelle avec succès des fonctions externes cdecl ou stdcall, sans connaître, ce 
qui se trouve oü. (Le nombre d'arguments, toutefois, doit étre spécifié). 


Il est possible de le résoudre en utilisant environ 5 à 10 instructions assembleur x86 
dans l'appelant. Essayez de trouver ca. 


6.1.10 Exemple cdecl: DLL 


Revenons au fait que la facon de déclarer la fonction main() n'est pas trés impor- 
tante: 1.9.2 on page 46. 


Ceci est une histoire vraie: il était une fois où je voulais remplacer un fichier original 
de DLL par le mien. Premiérement, j'ai énuméré les noms de tous les exports de 
la DLL et j'ai écrit une fonction dans ma propre DLL de remplacement pour chaque 
fonction de la DLL originale, comme: 


void functionl () 


1 


write to log ("functionl() called\n"); 


Je voulais voir quelles fonctions étaient appelées lors de l'exécution, et quand. Tou- 
tefois, j'étais pressé et n'avais pas le temps de déduire le nombre d'arguments pour 
chaque fonction, encore moins pour les types des données. Donc chaque fonction 
dans ma DLL de remplacement n'avait aucun argument que ce soit. Mais tout fonc- 
tionnait, car toutes les fonctions utilisaient la convention d'appel cdecl. (Ca ne fonc- 
tionnerait pas si les fonctions avaient la convention d'appel stdcall.) Ca a aussi fonc- 
tionné pour la version x64. 


Et puis j'ai fait une étape de plus: j'ai déduit les types des arguments pour certaines 
fonctions. Mais j'ai fait quelques erreurs, par exemple, la fonction originale prend 3 
arguments, mais je n'en ai découvert que 2, etc. 


Cependant, ca fonctionnait. Au début, ma DLL de remplacement ignorait simplement 
tous les arguments. Puis, elle ignorait le 3ème argument. 


6.2 Thread Local Storage 


TLS est un espace de données propre à chaque thread, qui peut y conserver ce qu'il 
estime utile. Un exemple d'utilisation bien connu en est la variable globale errno du 
standard C. 


Plusieurs threads peuvent invoquer simultanément différentes fonctions qui retournent 
toutes un code erreur dans la variable errno. L'utilisation d'une variable globale dans 
le contexte d'un programme comportant plusieurs threads serait donc inadaptée 
dans ce cas. C'est pourquoi la variable errno est conservée dans l'espace TLS. 


La version 11 du standard C++ a ajouté un nouveau modificateur thread local qui 
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indique que chaque thread posséde sa propre copie de la variable, qui peut-étre 
initialisée et est alors conservée dans l'espace TLS ^ : 


Listing 6.14 : C++11 


#include <iostream> 
#include <thread> 


thread local int tmp=3; 
int main() 


std::cout << tmp << std::endl; 
}; 


Compilé avec MinGW GCC 4.8.1, mais pas avec MSVC 2012. 


Dans le contexte des fichiers au format PE, la variable tmp sera allouée dans la 
section dédiée au TLS du fichier exécutable résultant de la compilation. 


6.2.1 Amélioration du générateur linéaire congruent 


Le générateur de nombres pseudo-aléatoires 1.29 on page 436 que nous avons étu- 
dié précédemment contient une faiblesse. Son comportement est buggé dans un 
environnement multi-thread. II utilise en effet une variable d'état dont la valeur peut 
étre lue et/ou modifiée par plusieurs threads simultanément. 


Win32 


Données TLS non initialisées 


Une solution consiste à déclarer la variable globale avec le modificateur declspec( 
thread ). Elle sera alors allouée dans le TLS (ligne 9) : 


#include «stdint.h» 
#include «windows.h» 
#include <winnt.h> 


// from the Numerical Recipes book: 
#define RNG a 1664525 

define RNG c 1013904223 

. declspec( thread ) uint32 t rand state; 


void my srand (uint32 t init) 


{ 
} 


rand state-init; 


int my rand () 


^ C11 supporte aussi les thread, mais optionel 
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1 
rand state-rand state*RNG a; 
rand state-rand state+RNG c; 
return rand state € Ox7fff; 
} 
int main() 
{ 
my srand(0x12345678); 
printf ("%d\n", my rand()); 
$; 


Hiew nous montre alors qu'il existe une nouvelle section nommée .tls dans le fichier 
PE. 


Listing 6.15 : avec optimisation MSVC 2013 x86 


_TLS SEGMENT 
_rand_state DD 01H DUP (?) 


TLS ENDS 

DATA SEGMENT 

$5G84851 DB '&d', OaH, OOH 
DATA ENDS 


TEXT | SEGMENT 


.init$ - 8 : size = 4 
_my_srand PROC 
; FS:0=address of TIB 


mov eax, DWORD PTR fs: tls array ; displayed in IDA as FS:2Ch 
; EAX=address of TLS of process 

mov ecx, DWORD PTR tls index 

mov ecx, DWORD PTR [eax+ecx*4] 
; ECX=current TLS segment 

mov eax, DWORD PTR  init$[esp-4] 

mov DWORD PTR rand state[ecx], eax 

ret 0 


.my srand ENDP 


my rand PROC 
; FS:0=address of TIB 


mov eax, DWORD PTR fs: tls array ; displayed in IDA as FS:2Ch 
; EAX=address of TLS of process 

mov ecx, DWORD PTR tls index 

mov ecx, DWORD PTR [eax+ecx*4] 


; ECX=current TLS segment 
imul eax, DWORD PTR rand state[ecx], 1664525 


add eax, 1013904223 ; 3c6ef35fH 
mov DWORD PTR rand state[ecx], eax 

and eax, 32767 ; 00007fffH 
ret 0 


.my rand ENDP 


TEXT ENDS 
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La variable rand_state se trouve donc maintenant dans le segment TLS et chaque 
thread en posséde sa propre version de cette variable. 


Voici comment elle est accédée. L'adresse du TIB est chargée depuis FS:2Ch, un 
index est ajouté (si nécessaire), puis l'adresse du segment TLS est calculée. 


Il est ainsi possible d'accéder la valeur de la variable rand_state au travers du 
registre ECX qui contient une adresse propre à chaque thread. 


Le sélecteur FS: est connu de tous les rétro-ingénieur. Il est spécifiquement utilisé 
pour toujours contenir l'adresse du TIB du thread en cours d'exécution. L'accés aux 
données propres à chaque thread est donc une opération performante. 


En environnement Win64, c'est le sélecteur GS: qui est utilisé pour ce faire. L'adresse 
de l'espace TLS y est conservé à l'offset 0x58 : 


Listing 6.16 : avec optimisation MSVC 2013 x64 


_TLS SEGMENT 
rand state DD 01H DUP (?) 


TLS ENDS 
DATA SEGMENT 

$5G85451 DB '&d', OaH, OOH 
DATA ENDS 


TEXT | SEGMENT 


init$ = 8 

my srand PROC 
mov edx, DWORD PTR tls index 
mov rax, QWORD PTR gs:88 ; 58h 
mov r8d, OFFSET FLAT:rand state 
mov rax, QWORD PTR [rax+rdx*8] 
mov DWORD PTR [r8+rax], ecx 
ret 0 


my srand ENDP 


my rand PROC 


mov rax, QWORD PTR gs:88 ; 58h 

mov ecx, DWORD PTR tls index 

mov edx, OFFSET FLAT:rand state 

mov rcx, QWORD PTR [rax+rcx*8] 

imul eax, DWORD PTR [rcx+rdx], 1664525 ; 0019660dH 
add eax, 1013904223 ; 3c6ef35fH 

mov DWORD PTR [rcx+rdx], eax 

and eax, 32767 ; 00007fffH 

ret 0 


my rand ENDP 


TEXT ENDS 


Initialisation des données TLS 
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Imaginons maintenant que nous voulons nous prémunir des erreurs de program- 
mation en initialisant systématiquement la variable rand state avec une valeur 
constante (ligne 9) : 


#include <stdint.h> 
#include «windows.h» 
#include <winnt.h> 


// from the Numerical Recipes book: 

#define RNG a 1664525 

#define RNG_c 1013904223 

. declspec( thread ) uint32 t rand_state=1234; 


void my srand (uint32 t init) 


1 
rand_state=init; 
} 
int my rand () 
1 
rand_state=rand_state*RNG_a; 
rand_state=rand_state+RNG_c; 
return rand state € Ox7fff; 
} 
int main() 
1 
printf ("%d\n", my rand()); 
}; 


Le code ne semble pas différent de celui que nous avons étudié. Pourtant dans IDA 
nous constatons: 


.tls:00404000 ; Segment type: Pure data 
.t1s:00404000 ; Segment permissions: Read/Write 


.tls:00404000 tls segment para public 'DATA' use32 

. tls :00404000 assume cs: tls 

.t1s:00404000 ;org 404000h 

.t1s:00404000 TlsStart db 0 ; DATA XREF: 
.rdata:TlsDirectory 

.t1s:00404001 db 0 

.tls :00404002 db 0 

.t1s:00404003 db 0 

.t1s:00404004 dd 1234 


.tls:00404008 TlsEnd db 0 ; DATA XREF: .rdata:TlsEnd ptr 


La valeur 1234 est bien présente. Chaque fois qu'un nouveau thread est créé, un 
nouvel espace TLS est alloué pour ses besoins et toutes les données - y compris 
1234 - y sont copiées. 


Considérons le scénario hypothétique suivant: 
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* Lethread A démarre. Un espace TLS est créé pour ses besoins et la valeur 1234 
est copiée dans rand state. 


* La fonction my rand() est invoquée plusieurs fois par le thread A. 
La valeur de la variable rand state est maintenant différente de 1234. 


* Le thread B démarre. Un espace TLS est créé pour ses besoins et la valeur 
1234 est copiée dans rand state. Dans le thread A, la valeur de rand state 
demeure différente de 1234. 


Fonctions de rappel TLS 


Mais comment procédons-nous si les variables conservées dans l'environnement TLS 
doivent étre initialisées avec des valeurs qui ne sont pas constantes ? 


Imaginons le scénario suivant: Il se peut que le programmeur oublie d'invoquer la 
fonction my srand() pour initialiser le PRNG. Malgré cela, le générateur doit étre ini- 
tialisé avec une valeur réellement aléatoire et non pas avec 1234. C'est précisément 
dans ce genre de cas que les fonctions de rappel TLS sont utilisées. 


Le code ci-dessous n'est pas vraiment portable du fait du bricolage, mais vous de- 
vriez comprendre l'idée. 


Nous définissons une fonction (tls callback()) qui doit étre invoquée avant le 
démarrage du processus et/ou d'un thread. 


Cette fonction initialise le PRNG avec la valeur retournée par la fonction GetTickCount(). 


#include <stdint.h> 
#include «windows.h» 
#include <winnt.h> 


// from the Numerical Recipes book: 
#define RNG a 1664525 

#define RNG c 1013904223 

. declspec( thread ) uint32 t rand state; 


void my srand (uint32 t init) 


1 
rand state-init; 
} 
void NTAPI tls callback(PVOID a, DWORD dwReason, PVOID b) 
{ 
my srand (GetTickCount()); 
} 


#pragma data seg(".CRT$XLB") 
PIMAGE TLS CALLBACK p thread callback - tls callback; 
#pragma data seg() 


int my rand () 


{ 
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rand_state=rand_state*RNG_a; 
rand_state=rand_state+RNG_c; 
return rand state € Ox7fff; 


I 
int main() 
1 
// rand state is already initialized at the moment (using 
GetTickCount()) 
printf ("%d\n", my rand()); 
$; 


Voyons cela dans IDA: 


Listing 6.17 : avec optimisation MSVC 2013 


.text:00401020 TlsCallback © proc near ; DATA XREF: 
.rdata:TlsCallbacks 

.text:00401020 call ds:GetTickCount 

.text:00401026 push eax 

.text:00401027 call my srand 

.text:0040102C pop ecx 

.text:0040102D retn OCh 


.text:0040102D TlsCallback © endp 


.rdata:004020C0 TlsCallbacks dd offset TlsCallback_0 ; DATA XREF: 
.rdata:TlsCallbacks ptr 


.rdata:00402118 TlsDirectory dd offset TlsStart 
.rdata:0040211C TlsEnd ptr dd offset TlsEnd 
.rdata:00402120 TlsIndex ptr dd offset TlsIndex 
.rdata:00402124 TlsCallbacks ptr dd offset TlsCallbacks 
.rdata:00402128 TlsSizeOfZeroFill dd 0 

.Fdata:0040212C TlsCharacteristics dd 300000h 


Les fonctions de rappel TLS sont parfois utilisées par les mécanismes de décompres- 
sion d'exécutable afin d'en rendre le fonctionnement plus obscure. 


Cette pratique peut en laisser certains dans le noir parce qu'ils auront omis de consi- 
dérer qu'un fragment de code a pu s'exécuter avant l'OEP?. 
Linux 


Voyons maintenant comment une variable globale conservée dans l'espace de sto- 
ckage propre au thread est déclarée avec GCC: 


. thread uint32 t rand state-1234; 


5Original Entry Point 
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Il ne s'agit pas du modificateur standard C/C++ modifier, mais bien d'un modifica- 
teur spécifique à GCC ©. 


Le sélecteur GS: est utilisé lui aussi pour accéder au TLS, mais d'une maniére un 
peu différente: 


Listing 6.18 : avec optimisation GCC 4.8.1 x86 


.text:08048460 my srand proc near 

.text:08048460 

.text:08048460 arg 0 = dword ptr 4 
.text:08048460 

.text:08048460 mov eax, [esp+arg 0] 

. text: 08048464 mov gs:OFFFFFFFCh, eax 
. text: 0804846A retn 

. text: 0804846A my srand endp 

.text:08048470 my rand proc near 

.text:08048470 imul eax, gs:OFFFFFFFCh, 19660Dh 
.text:0804847B add eax, 3C6EF35Fh 

. text: 08048480 mov gs:OFFFFFFFCh, eax 
. text: 08048486 and eax, 7FFFh 

. text: 0804848B retn 

.text:0804848B my_rand endp 


Pour en savoir plus: [Ulrich Drepper, ELF Handling For Thread-Local Storage, (2013)]’. 


6.3 Appels systemes (syscall-s) 


Comme nous le savons, tous les processus d’un OS sont divisés en deux catégories: 
ceux qui ont un accés complet au matériel («kernel space » espace noyau) et ceux 
qui ne l'ont pas («user space » espace utilisateur). 


Le noyau de l'OS et, en général, les drivers sont dans la premiére catégorie. 
Toutes les applications sont d'habitude dans la seconde catégorie. 


Par exemple, le noyai Linux est dans le kernel space, mais la Glibc est dans le user 
space. 


Cette séparation est cruciale pour la sécurité de l'OS : il est tres important de ne 
pas donner la possibilité à n'importe quel processus de casser quelque chose dans 
un autre processus ou méme dans le noyau de l'OS. D'un autre cóté, un driver qui 
plante ou une erreur dans le noyau de l'OS se termine en général par un kernel panic 
ou un BSOD?. 


La protection en anneau dans les processeurs x86 permet de séparer l'ensemble 
dans quatre niveaux de protection (rings), mais tant dans Linux que Windows, seuls 
deux d'entre eux sont utilisés: ringO («kernel space ») et ring3 («user space »). 


$https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/C99- Thread-Local-Edits.html 
"Aussi disponible en http: //www.akkadia.org/drepper/tls.pdf 
9Blue Screen of Death 
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Les appels systémes (syscall-s) sont un point oü deux espaces sont connectés. 


On peut dire que c'est la principale API fournie aux applications. 
Comme dans Windows NT, la table des appels systéme se trouve dans la SSDT?. 


L'utilisation des appels systéme est trés répandue parmi les auteurs de shellcode et 
de virus, car il est difficile de déterminer l'adresse des fonctions nécessaires dans 
les bibliothéques systéme, mais il est simple d'utiliser les appels systéme. Toutefois, 
il est nécessaire d'écrire plus de code à cause du niveau d'abstraction plus bas de 
l'API. 


Il faut aussi noter que les numéros des appels systémes peuvent étre différent dans 
différentes versions d'un OS. 
6.3.1 Linux 


Sous Linux, un appel systéme s'effectue d'habitude par int 0x80. Le numéro de 
l'appel est passé dans le registre EAX, et tout autre paramétre —dans les autres 
registres. 


Listing 6.19 : Un exemple simple de l'utilisation de deux appels systéme 


section .text 
global start 


start: 
mov edx,len ; buffer len 
mov ecx,msg ; buffer 
mov ebx,1 ; file descriptor. 1 is for stdout 
mov eax,4 ; Syscall number. 4 is for sys write 
int 0x80 
mov eax,1 ; Syscall number. 1 is for sys exit 
int 0x80 


section .data 


msg db ‘Hello, world!',0xa 
len equ $ - msg 


Compilation: 


nasm -f elf32 1.s 
ld 1.0 


La liste compléte des appels systémes sous Linux: http://syscalls.kernelgrok. 
com/. 


Pour intercepter les appels systéme et les suivre sous Linux, strace(7.2.3 on page 1032) 
peut étre utilisé. 


9System Service Dispatch Table 
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6.3.2 Windows 


Ici, ils sont appelés via int 0x2e ou en utilisant l'instruction x86 spéciale SYSENTER. 


La liste complète des appels systèmes sous Windows: http://j00ru.vexillium. 
org/ntapi/. 


Pour aller plus loin: 


«Windows Syscall Shellcode » par Piotr Bania: http: //www.symantec.com/connect/ 
articles/windows-syscall-shellcode. 


6.4 Linux 


6.4.1 Code indépendant de la position 


Lorsque l'on analyse des bibliothéques partagées sous Linux (.so), on rencontre sou- 
vent ce genre de code: 


Listing 6.20 : libc-2.17.so x86 


.text:0012D5E3 x86 get pc thunk bx proc near ; CODE XREF: sub 1735043 
.text:0012D5E3 ; sub 173CC+4 ... 
.text:0012D5E3 mov ebx, [esp+0] 

.text:0012D5E6 retn 


.text:0012D5E6 x86 get pc thunk bx endp 


.text:000576C0 sub 576C0 proc near ; CODE XREF: tmpfile+73 

.text:000576C0 push ebp 

.text:000576C1 mov ecx, large gs:0 

.text:000576C8 push edi 

.text:000576C9 push esi 

.text:000576CA push ebx 

.text:000576CB call x86 get pc thunk bx 

.text:000576D0 add ebx, 157930h 

.text:000576D6 sub esp, 9Ch 

.text:000579F0 lea eax, (a gen tempname - 1AF000h)[ebx] ; 
" gen tempname" 

.text:000579F6 mov [esp+0ACh+var_A0], eax 

.text:000579FA lea eax, (a SysdepsPosix - 1AF000h) [ebx] ; 
"../sysdeps/posix/tempname.c" 

.text:00057A00 mov [esp+0ACh+var_A8], eax 

.text:00057A04 lea eax, (alInvalidKindIn - 1AF000h)[ebx] ; 
"1 N"invalid KIND in gen tempnameV" " 

.text:00057A0A mov [esp+0ACh+var_A4], 14Ah 


.text:00057A12 mov [esp+0ACh+var_AC], eax 
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.text:00057A15 


call 


. assert fail 


Tous les pointeurs sur des chaínes sont corrigés avec une certaine constante et la 
valeur de EBX, qui est calculée au début de chaque fonction. 


C'est ce que l'on appelle du code PIC, qui peut étre exécuté à n'importe quelle 


adresse mémoire, c'est pourquoi il ne doit contenir aucune adresse absolue. 


PIC était crucial dans les premiers ordinateurs, et l'est encore aujourd'hui dans les 
systémes embarqués sans support de la mémoire virtuelle (oú tous les processus se 
trouvent dans un seul bloc continu de mémoire). 


C'est encore utilisé sur les systémes *NIX pour les bibliothéques partagées, car elles 
sont utilisées par de nombreux processus mais ne sont chargées qu'une seule fois en 
mémoire. Mais tous ces processus peuvent mapper la méme bibliothéque partagée 
à des adresses différentes, c'est pourquoi elles doivent fonctionner correctement 


sans aucune adresse absolue. 


Faisons un petit essai: 


#include <stdio.h> 


int global_variable=123; 


int fl(int var) 


{ 


int rt=global_variable+var; 
printf ("returning %d\n", rt); 
return rt; 


}; 


Compilons le avec GCC 4.7.3 et examinons le fichier .so généré dans IDA : 


gcc -fPIC -shared -03 -o 1.so 1.c 


Listing 6.21 : GCC 4.7.3 


.text: 
.text: 


00000440 
00000440 


CODE XREF: 


.text: 


00000440 


deregister 


.text: 
.text: 
:00000443 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


00000440 
00000443 


00000570 
00000570 
00000570 
00000570 
00000570 
00000570 
00000570 
00000570 


public x86 get pc thunk bx 


x86 get pc thunk bx proc near ; 


init proc+4 


tm clones+4 ... 


mov ebx, [esp+0] 
retn 


x86 get pc thunk bx endp 


f1 


var 1C 
var 18 
var 14 
var 8 
var 4 


public f1 
proc near 


dword ptr -1Ch 
dword ptr -18h 
dword ptr -14h 
dword ptr -8 
dword ptr -4 
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.text:00000570 arg_0 = dword ptr 4 

.text:00000570 

.text:00000570 sub esp, 1Ch 

.text:00000573 mov [esp+1Ch+var_8], ebx 

.text:00000577 call x86 get pc thunk bx 

.text:0000057C add ebx, 1A84h 

.text:00000582 mov [esp+1Ch+var_4], esi 

.text:00000586 mov eax, ds:(global variable ptr - 2000h7 
& ) [ebx] 

.text:0000058C mov esi, [eax] 

.text:0000058E lea eax, (aReturningD - 2000h)[ebx] ; 
"returning %d\n" 

.text:00000594 add esi, [esp+1Ch+arg_0] 

.text:00000598 mov [esp+1Ch+var_18], eax 

.text:0000059C mov [esp+1Ch+var 1C], 1 

.text:000005A3 mov [esp+1Ch+var_14], esi 

.text:000005A7 call ||  printf chk 

.text:000005AC mov eax, esi 

.text:000005AE mov ebx, [esp+1Ch+var_8] 

.text:000005B2 mov esi, [esp+1Ch+var 4] 

.text : 000005B6 add esp, 1Ch 

. text : 000005B9 retn 

.text:000005B9 f1 endp 


C'est ça: les pointeurs sur «returning %d\n» et global variable sont corrigés à chaque 
exécution de la fonction. 


La fonction x86 get pc thunk bx() renvoie dans EBX l'adresse de l'instruction 
aprés son appel (0x57C ici). 


C'est un moyen simple d'obtenir la valeur du compteur de programme (EIP) à un 
endroit quelconque. La constante 0x1A84 est relative à la différence entre le début 
de cette fonction et ce que l'on appelle Global Offset Table Procedure Linkage Table 
(GOT PLT), la section juste aprés la Global Offset Table (GOT), où se trouve le pointeur 
sur global variable. IDA montre ces offsets sous leur forme calculée pour rendre les 
choses plus facile à comprendre, mais en fait, le code est: 


.text:00000577 call x86 get pc thunk bx 
.text:0000057C add ebx, 1A84h 
.text:00000582 mov [esp+1Ch+var_4], esi 
.text:00000586 mov eax, [ebx-0Ch] 
.text:0000058C mov esi, [eax] 
.text:0000058E lea eax, [ebx-1A30h] 


Ici, EBX pointe sur la section GOT PLT et pour calculer le pointeur sur global variable 
( qui est stocké dans la GOT), il faut soustraire OxC. 


Pour calculer la valeur du pointeur sur la chaine «returning 96d|n», il faut soustraire 
0x1A30. 


A propos, c’est la raison pour laquelle le jeu d’instructions AMD64 ajoute le support 
d'adressage relatif de RIP!? — pour simplifier le code PIC. 


10 compteur de programme sur AMD64 
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Compilons le méme code C en utilisant la méme version de GCC, mais pour x64. 


IDA simplifierait le code en supprimant les détails de l'adressage relatif à RIP, donc 
utilisons objdump à la place d'IDA pour tout voir: 


0000000000000720 <f1>: 


720: 48 8b 05 b9 08 20 00 mov rax,QWORD PTR [rip+0x2008b9] 2 
S 
200fe0 « DYNAMIC+0x1d0> 

727: 53 push rbx 

728: 89 fb mov ebx,edi 


72a: 48 8d 35 20 00 00 00 lea rsi, [rip+0x20] ; 
751 « fini+0x9> 


731: bf 01 00 00 00 mov edi, 0x1 

736: 03 18 add ebx,DWORD PTR [rax] 
738: 31 c0 xor eax,eax 

73a: 89 da mov edx,ebx 

73c: e8 df fe ff ff call 620 « printf chk@plt> 
741: 89 d8 mov eax,ebx 

743: 5b pop rbx 

744: c3 ret 


0x2008b9 est la différence entre l'adresse de l'instruction en 0x720 et global variable, 
et 0x20 est la différence entre l'adresse de l'instruction en 0x72A et la chaîne «retur- 
ning %d\n». 


Comme on le voit, le fait d'avoir à recalculer fréquemment les adresses rend l'exé- 
cution plus lente (cela dit, ca c'est amélioré en x64). 


Donc, il est probablement mieux de lier statiquement si vous vous préoccupez des 
performances [voir: Agner Fog, Optimizing software in C++ (2015)]. 


Windows 


Le mécanisme PIC n'est pas utilisé dans les DLLs de Windows. Si le chargeur de 
Windows doit charger une DLL à une autre adresse, il «patche » la DLL en mémoire 
(aux places FIXUP) afin de corriger toutes les adresses. 


Cela implique que plusieurs processus Windows ne peuvent pas partager une DLL 
déjà chargée à une adresse différente dans des blocs mémoire de différents proces- 
sus — puisque chaque instance qui est chargée en mémoire est fixé pour fonctionner 
uniquement à ces adresses... 


6.4.2 Hack LD PRELOAD sur Linux 


Cela permet de charger nos propres bibliothéques dynamiques avant les autres, 
méme celle du systéme, comme libc.so.6. 


Cela permet de «substituer » nos propres fonctions, avant celles originales des biblio- 
théques du systéme. Par exemple, il est facile d'intercepter tous les appels à time(), 
read(), write(), etc. 


Regardons si l'on peut tromper l'utilitaire uptime. Comme chacun le sait, il indique 
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depuis combien de temps l'ordinateur est démarré. Avec l'aide de strace(7.2.3 on 
page 1032), on voit que ces informations proviennent du fichier /proc/uptime : 


$ strace uptime 


open("/proc/uptime", O RDONLY) = 3 
lseek(3, 0, SEEK_SET) =0 
= 20 


read(3, "416166.86 414629.381n", 2047) 


Ce n'est pas un fichier réel sur le disque, il est virtuel et généré au vol par le noyau 
Linux. Il y a seulement deux nombres: 


$ cat /proc/uptime 
416690.91 415152.03 


Ce que l'on peut apprendre depuis Wikipédia !1 : 


Le premier est le nombre total de seconde depuis lequel le systéme 
est démarré. Le second est la part de ce temps pendant lequel la ma- 
chine était inoccupée, en secondes. 


Essayons d'écrire notre propre bibliothéque dynamique, avec les fonctions open(), 
read(), close() fonctionnant comme nous en avons besoin. 


Tout d'abord, notre fonction open() va comparer le nom du fichier à ouvrir avec celui 
que l'on veut modifier, et si c'est le cas, sauver le descripteur du fichier ouvert. 


Ensuite, si read() est appelé avec ce descripteur de fichier, nous allons substituer 
la sortie, et dans les autres cas, nous appellerons la fonction read() originale de 
libc.so.6. Et enfin close() fermera le fichier que nous suivons. 


Nous allons utiliser les fonctions dlopen() et dlsym() pour déterminer les adresses 
des fonctions originales dans libc.so.6. 


Nous en avons besoin pour appeler les fonctions «réelles ». 


D'un autre cóté, si nous interceptons strcmp() et surveillons chaque comparaison de 
chaines dans le programme, nous pouvons alors implémenter notre propre fonction 
strcmp(), et ne pas utiliser la fonction originale du tout. 


12 


#include <stdio.h> 
#include <stdarg.h> 
#include <stdlib.h> 
#include <stdbool.h> 
#include <unistd.h> 
#include <dlfcn.h> 
#include <string.h> 


llwikipédia 
12Par exemple, voilà comment implémenter une interception simple de strcmp() dans cet article 13 écrit 
par Yong Huang 
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void *libc handle = NULL; 

int (*open ptr) (const char *, int) = NULL; 

int (*close ptr)(int) = NULL; 

ssize t (*read ptr)(int, void*, size t) = NULL; 


bool inited = false; 


_Noreturn void die (const char * fmt, ...) 
1 

va list va; 

va start (va, fmt); 


vprintf (fmt, va); 
exit(0); 
}; 


static void find original functions () 
{ 
if (inited) 
return; 


libc handle = dlopen ("libc.so.6", RTLD LAZY); 
if (libc_handle==NULL) 
die ("can't open libc.so.6Xn"); 


open ptr = dlsym (libc handle, "open"); 
if (open_ptr==NULL) 
die ("can't find open()\n"); 


close ptr = dlsym (libc handle, "close"); 
if (close ptr==NULL) 
die ("can't find close()\n"); 


read ptr = dlsym (libc handle, "read"); 
if (read ptr-zNULL) 
die ("can't find read()\n"); 


inited - true; 


} 
static int opened_fd=0; 


int open(const char *pathname, int flags) 
{ 


find original functions(); 


int fd-(*open ptr)(pathname, flags); 
if (strcmp(pathname, "/proc/uptime")==0) 
opened fd-fd; // that's our file! record its file descriptor 
else 
opened fd-0; 
return fd; 
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}; 
int close(int fd) 
{ 
find_original_functions(); 
if (fd==opened_ fd) 
opened fdz0; // the file is not opened anymore 
return (*close ptr) (fd); 
}; 
ssize t read(int fd, void *buf, size t count) 
{ 
find original functions(); 
if (opened fd!=0 && fd--opened fd) 
1 
// that's our file! 
return snprintf (buf, count, "%d %d", Ox7fffffff, Ov 
S X7fffffff)41; 
}; 
// not our file, go to real read() function 
return (*read_ptr)(fd, buf, count); 
}; 


( Code source ) 
Compilons le comme une bibliothèque dynamique standard: 


gcc -fpic -shared -Wall -o fool uptime.so fool uptime.c -ldl 


Lancons uptime en chargeant notre bibliothéque avant les autres: 


LD PRELOAD-'pwd'/fool uptime.so uptime 


Et nous voyons: 


01:23:02 up 24855 days, 3:14, 3 users, load average: 0.00, 0.01, 0.05 


Si la variable d'environnement LD PRELOAD 

pointe toujours sur le nom et le chemin de notre bibliothéque, elle sera chargée pour 
tous les programmes démarrés. 

Plus d'exemples: 


e Interception simple de strcmp() (Yong Huang) https: //yurichev.com/mirrors/ 
LD PRELOAD/Yongss20Huangs20LD PRELOAD.txt 


* Kevin Pulo—Jouons avec LD PRELOAD. De nombreux exemples et idées. yuri- 
chev.com 


* |nterception des fonctions de fichier pour compresser/décompresser les fichiers 
au vol (zlibc) ftp://metalab.unc.edu/pub/Linux/libs/compression 


m 
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6.5 Windows NT 
6.5.1 CRT (win32) 


L'exécution du programme débute donc avec la fonction main() ? Non, pas du tout. 


Ouvrez un exécutable dans IDA ou HIEW, et vous constaterez que l'OEP pointe sur 
un bloc de code qui se situe ailleurs. 


Ce code prépare l'environnement avant de passer le contróle à notre propre code. 
Ce fragment de code initial est dénommé CRT (pour C RunTime). 


La fonction main() accepte en arguments un tableau des paramétres passés en 
ligne de commande, et un autre contenant les variables d'environnement. En réa- 
lité, ce qui est passé au programme est une simple chaine de caractéres. Le code 
du CRT repère les espaces dans la chaîne et découpe celle-ci en plusieurs morceaux 
qui constitueront le tableau des paramétres. Le CRT est également responsable de 
la préparation du tableau des variables d'environnement envp. 


En ce qui concerne les applications win32 dotées d'un interface graphique (GUI?^). 
La fonction principale est nommée WinMain et non pas main(). Elle posséde aussi 
ses propres arguments: 


int CALLBACK WinMain( 
.In  HINSTANCE hInstance, 
_In_  HINSTANCE hPrevInstance, 
_In_ LPSTR lpCmdLine, 
_In_ int nCmdShow 

); 


C’est toujours le CRT qui est responsable de leurs préparation. 


La valeur retournée par la fonction main() est également ce qui constitue le code 
retour du programme. 


Le CRT peut utiliser cette valeur lors de l'appel de la fonction ExitProcess() qui 
prend le code retour du programme en paramétre. 


En regle générale, le code du CRT est propre a chaque compilateur. 


Voici celui du MSVC 2008. 


. tmainCRTStartup proc near 


var_24 = dword ptr -24h 

var_20 = dword ptr -20h 

var_1C = dword ptr -1Ch 

ms_exc = CPPEH_RECORD ptr -18h 
push 14h 
push offset stru 4092D0 
call . SEH prolog4 


l4Graphical User Interface 
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mov 
cmp 
jnz 
mov 
cmp 
jnz 
mov 
cmp 
jnz 
cmp 
jbe 
xor 
cmp 
setnz 
mov 
jmp 


loc 401096: 
and 


loc 401094: 
push 
call 
pop 
test 
jnz 
push 
call 
pop 


loc 4010AE: 
call 
test 
jnz 
push 
call 
pop 


loc 4010BF: 
call 
and 
call 
test 
jge 
push 
call 
pop 


loc 4010D9: 
call 
mov 


, 


, 


, 


, 


, 


, 


eax, 5A4Dh 

ds:400000h, ax 

short loc 401096 

eax, ds:40003Ch 

dword ptr [eax+400000h], 4550h 
short loc 401096 

ecx, 10Bh 

[eax-400018h], cx 

short loc 401096 

dword ptr [eax+400074h], OEh 
short loc 401096 

ecx, ecx 

[eax+4000E8h], ecx 

cl 

[ebp+var_1C], ecx 

short loc_40109A 


; CODE XREF: tmainCRTStartup+18 
tmainCRTStartup+29 ... 
[ebp+var_1C], 0 
; CODE XREF: tmainCRTStartup+50 
1 
. heap init 
ecx 
eax, eax 
short loc 4010AE 
1Ch 
fast error exit 
ecx 
; CODE XREF: tmainCRTStartup+60 
. mtinit 
eax, eax 
short loc 4010BF 
10h 
fast error exit 
ecx 
; CODE XREF: tmainCRTStartup+71 
sub_401F2B 
[ebp+ms exc.disabled], 0 
__ioinit 
eax, eax 
short loc 4010D9 
1Bh 
. amsg exit 
ecx 
; CODE XREF: tmainCRTStartup+8B 


ds :GetCommandLineA 
dword_40B7F8, eax 
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call 
mov 
call 
test 
jge 
push 
call 
pop 


loc 4010FF: 
call 
test 
jge 
push 
call 
pop 


loc 401110: 


loc 401123: 
mov 
mov 
push 
push 
push 
call 
add 
mov 
cmp 
jnz 
push 
call 


$LN28: 
call 
jmp 


$LN27: 
mov 


401044 
mov 


mov 
mov 

push 
push 


, 


, 


, 


, 


, 


_  crtGetEnvironmentStringsA 
dword_40AC60, eax 

_ setargv 

eax, eax 

short loc 4010FF 

8 

. amsg exit 

ecx 


; CODE XREF: tmainCRTStartup+B1 


. setenvp 

eax, eax 

short loc 401110 
9 

_ amsg exit 

ecx 


; CODE XREF: tmainCRTStartup+C2 


1 

. cinit 

ecx 

eax, eax 

short loc 401123 
eax 

. amsg exit 

ecx 


; CODE XREF: tmainCRTStartup+D6 


eax, envp 
dword 40AC80, eax 

eax ; envp 
argv ; argv 
argc ; argc 
main 

esp, OCh 

[ebp+var 20], eax 
[ebp-var 1C], 0 

short $LN28 


eax ; uExitCode 
$LN32 
CODE XREF: tmainCRTStartup+105 
__cexit 


short loc 401186 


; DATA XREF: .rdata:stru 4092D0 


eax, [ebp+ms exc.exc ptr] ; Exception filter 0 for function 


ecx, [eax] 

ecx, [ecx] 
[ebp+var 24], ecx 
eax 

ecx 
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call _ XcptFilter 
pop ecx 
pop ecx 
$LN24: 
retn 
$LN14: ; DATA XREF: .rdata:stru 4092D0 
mov esp, [ebp+ms exc.old esp] ; Exception handler O for function 
401044 
mov eax, [ebp+var 24] 
mov [ebp+var_20], eax 
cmp [ebp+var_1C], 0 
jnz short $LN29 
push eax £ int 
call | exit 
$LN29: ; CODE XREF: tmainCRTStartup+135 
call . C exit 
loc 401186: ; CODE XREF: tmainCRTStartup+112 
mov [ebp+ms_exc.disabled], OFFFFFFFEh 
mov eax, [ebp+var_20] 
call _ SEH epilog4 
retn 


Nous y trouvons des appels à GetCommandLineA() (line 62), puis setargv() (line 
66) et setenvp() (line 74), qui semblent étre utilisés pour initialiser les variables 
globales argc, argv, envp. 


Enfin, main() est invoqué avec ces arguments (line 97). 


Nous observons également des appels à des fonctions au nom évocateur telles que 
heap init() (line 35), ioinit() (line 54). 


Le tas heap est lui aussi initialisé par le CRT. Si vous tentez d'utiliser la fonction 
malloc() dans un programme ou le CRT n'a pas été ajouté, le programme va s'ache- 
ver de maniére anormale avec l'erreur suivante: 


runtime error R6030 
- CRT not initialized 


L'initialisation des objets globaux en C++ est également de la responsabilité du CRT 
avant qu'il ne passe la main à main() : 3.21.4 on page 729. 


La valeur retournée par main() est passée soit à la fonction cexit(), soit à $LN32 
qui à son tour invoque doexit(). 


Mais pourrait-on se passe du CRT ? Oui, si vous savez ce que vous faites. 


L'éditeur de lien MSVC accepte une option /ENTRY qui permet de définir le point 
d'entrée du programme. 
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#include «windows.h» 


int main() 


1 
}; 


MessageBox (NULL, "hello, world", "caption", MB OK); 


Compilons ce programme avec MSVC 2008. 


cl no_crt.c user32.lib /link /entry:main 


Nous obtenons un programme exécutable .exe de 2560 octets qui contient en tout 
et pour tout l'en-téte PE, les instructions pour invoquer MessageBox et deux chaines 
de caracteres dans le segment de données: le nom de la fonction MessageBox et 
celui de sa DLL d'origine user32.dll. 


Cela fonctionne, mais vous ne pouvez pas déclarer WinMain et ses 4 arguments à la 
place de main(). 


Pour étre précis, vous pourriez, mais les arguments ne seraient pas préparés au 
moment de l'exécution du programme. 


Cela étant, il est possible de réduire encore la taille de l'exécutable en utilisant une 
valeur pour l'alignement des sections du fichier au format PE une valeur inférieur à 
celle par défaut de 4096 octets. 


cl no crt.c user32.lib /link /entry:main /align:16 


L'éditeur de lien prévient cependant: 


LINK : warning LNK4108: /ALIGN specified without /DRIVER; image may not run 


Nous pouvons ainsi obtenir un exécutable de 720 octets. Son exécution est possible 
sur Windows 7 x86, mais pas en environnement x64 (un message d'erreur apparaítra 
alors si vous tentez de l'exécuter). 


Avec des efforts accrus il est possible de réduire encore la taille, mais avec des 
problémes de compatibilité comme vous le voyez. 


6.5.2 Win32 PE 


PE est un format de fichier exécutable utilisé sur Windows. La différence entre .exe, 
.dil et .sys est que les .exe et .sys n'ont en général pas d'exports, uniquement des 
imports. 


Une DLLP, tout comme n'importe quel fichier PE, possède un point d'entrée (OEP) 
(la fonction DIIMain() se trouve là) mais cette fonction ne fait généralement rien. .sys 
est généralement un pilote de périphérique. Pour les pilotes, Windows exige que la 
somme de contróle soit présente dans le fichier PE et qu'elle soit correcte 16. 


15Dynamic-Link Library 
16Par exemple, Hiew(7.1 on page 1029) peut la calculer 


986 


A partir de Windows Vista, un fichier de pilote doit aussi étre signé avec une signature 
numérique. Le chargement échouera sinon. 


Chaque fichier PE commence avec un petit programme DOS qui affiche un message 
comme «Ce programme ne peut pas étre lancé en mode DOS. »—si vous lancez sous 
DOS ou Windows 3.1 (OS-es qui ne supportent pas le format PE), ce message sera 
affiché. 


Terminologie 


* Module—un fichier séparé, .exe ou .dll. 


* Process—un programme chargé dans la mémoire et fonctionnant actuellement. 
Consiste en général d'un fichier .exe et d'un paquet de fichiers .dll. 


* Process memory—la mémoire utilisée par un processus. Chaque processus a la 
sienne. Il y a en général des modules chargés, la mémoire pour la pile, tas(s), 
etc. 


* VAY —une adresse qui est utilisée pendant le déroulement du programme. 


* Base address (du module)—l'adresse dans la mémoire du processus à laquelle 
le module est chargé. Le chargeur de l'OS peut la changer, si l'adresse de base 
est occupée par un module déjà chargé. 


e RVAÏ8_ l'adresse VA-moins l'adresse de base. 
De nombreuses adresses dans les fichiers PE utilisent l'adresse RVA. 


* AT! un tableau d'adresses des symboles importés 20. 
Parfois, le répertoire de données IMAGE DIRECTORY ENTRY IAT pointe sur l'IAT. 
Il est utile de noter qu'IDA (à partir de 6.1) peut allouer une pseudo-section 
nommée .idata pour l'IAT, méme si l'IAT fait partie d'une autre section! 


* INT?! —une tableau de noms de symboles qui doivent être importés??. 


Adresse de base 


Le probléme est que plusieurs auteurs de module peuvent préparer des fichiers DLL 
pour que d'autres les utilisent et qu'il n'est pas possible de s'accorder pour assigner 
une adresse à ces modules. 


C'est pourquoi si deux DLLs nécessaires pour un processus ont la méme adresse 
de base, une des deux sera chargée à cette adresse de base, et l'autre—à un autre 
espace libre de la mémoire du processus et chaque adresse virtuelle de la seconde 
DLL sera corrigée. 


Virtual Address 

18Relative Virtual Address 

19import Address Table 

20Matt Pietrek, An In-Depth Look into the Win32 Portable Executable File Format, (2002)] 
?llmport Name Table 

22Matt Pietrek, An In-Depth Look into the Win32 Portable Executable File Format, (2002)] 
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Avec MSVC l'éditeur de lien génére souvent les fichiers .exe avec une adresse de 
base en 0x4000007?, et avec une section de code débutant en 0x401000. Cela signifie 
que la RVA du début de la section de code est 0x1000. 


Les DLLs sont souvent générées par l'éditeur de lien de MSVC avec une adresse de 
base de 0x10000000?*, 


Il y a une autre raison de charger les modules a des adresses de base variées, aléa- 
toires dans ce cas. C'est l'ASLR?*. 


Un shellcode essayant d'étre exécuté sur une systéme compromis doit appeler des 
fonctions systémes, par conséquent, connaítre leurs adresses. 


Dans les anciens OS (dans la série Windows NT : avant Windows Vista), les DLLs 
systéme (comme kernel32.dll, user32.dll) étaient toujours chargées à une adresse 
connue, et si nous nous rappelons que leur version changeait rarement, l'adresse 
des fonctions était fixe et le shellcode pouvait les appeler directement. 


Pour éviter ceci, la méthode ASLR charge votre programme et tous les modules dont 
il a besoin à des adresses de base aléatoires, différentes à chaque fois. 


Le support de l'ASLR est indiqué dans un fichier PE en mettant le flag 
IMAGE DLL CHARACTERISTICS DYNAMIC BASE [voir Mark Russinovich, Microsoft Win- 
dows Internals]. 


Sous-systéme 

Il a aussi un champ sous-systéme, d'habitude c'est: 
e natif?? (.sys-driver), 
* console (application en console) ou 


* GUI (non-console). 


Version d'OS 


Un fichier PE indique aussi la version de Windows minimale requise pour pouvoir étre 
chargé. 

La table des numéros de version stockés dans un fichier PE et les codes de Windows 
correspondants est ici?". 


Par exemple, MSVC 2005 compile les fichiers .exe pour tourner sur Windows NT4 
(version 4.00), mais MSVC 2008 ne le fait pas (les fichiers générés ont une version 
de 5.00, il faut au moins Windows 2000 pour les utiliser). 


23L'origine de ce choix d'adresse est décrit ici: MSDN 

24Cela peut étre changé avec l'option /BASE de l'éditeur de liens 
?5Wikipédia 

26Signifiant que le module utilise l'API Native au lieu de Win32 
?" Wikipédia 
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MSVC 2012 génere des fichiers .exe avec la version 6.00 par défaut, visant au moins 
Windows Vista. Toutefois, en changeant l'option du compilateur??, il est possible de 
le forcer à compiler pour Windows XP. 


Sections 


Il semble que la division en section soit présente dans tous les formats de fichier 
exécutable. 


C'est divisé afin de séparer le code des données, et les données—des données 
constantes. 


* Sil'un des flags IMAGE SCN CNT CODE ou IMAGE SCN MEM EXECUTE est mis 
dans la section de code—c'est de code exécutable. 


Dans la section de données—les flags IMAGE SCN CNT INITIALIZED DATA, 
IMAGE SCN MEM READ et IMAGE SCN MEM WRITE. 


Dans une section vide avec des données non initialisées— 
IMAGE SCN CNT. UNINITIALIZED DATA, IMAGE SCN MEM READ et 
IMAGE SCN MEM WRITE. 


Dans une section de données constantes (une qui est protégée contre l'écri- 
ture), les flags IMAGE SCN CNT.INITIALIZED DATA et IMAGE SCN MEM READ 
peuvent être mis, mais pas IMAGE SCN MEM WARITE. Un processus plantera s'il 
essaye d'écrire dans cette section. 


Chaque section dans un fichier PE peut avoir un nom, toutefois, ce n'est pas trés im- 
portant. (peut-être que .rdata signifie read-only-data). Souvent (mais pas toujours) 
la section de code est appelée .text, la section de données— .data, la section de 
données constante — .rdata (readable data). D'autres noms de section courants 
sont: 


e .idata—section d'imports. IDA peut créer une pseudo-section appelée ainsi: 
6.5.2 on page 986. 


e .edata—section d'exports section (rare) 


* .pdata—section contenant toutes les informations sur les exceptions dans Win- 
dows NT pout MIPS, IA64 et x64: 6.5.3 on page 1021 


e .reloc—section de relocalisation 

* .bss—données non initialisées (BSS) 

e ,tls—stockage local d'un thread (TLS) 
e .rsrc—ressources 


* .CRT— peut étre présente dans les fichiers binaire compilés avec des anciennes 
versions de MSVC 


Les packeurs/chiffreurs rendent souvent les noms de sections inintelligibles ou les 
remplacent avec des noms qui leurs sont propres. 


28MSDN 
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MSVC permet de déclarer des données dans une section de n'importe quel nom ??. 


Certains compilateurs et éditeurs de liens peuvent ajouter une section avec des sym- 
boles et d'autres informations de débogage (MinGW par exemple). Toutefois ce n'est 
pas comme cela dans les derniéres versions de MSVC (des fichiers PDB séparés sont 
utilisés dans ce but). 


Voici comment une section PE est décrite dans le fichier: 


typedef struct IMAGE SECTION HEADER { 
BYTE Name[IMAGE SIZEOF SHORT NAME]; 
union 1 
DWORD PhysicalAddress; 
DWORD VirtualSize; 
} Misc; 
DWORD VirtualAddress; 
DWORD SizeOfRawData; 
DWORD PointerToRawData; 
DWORD PointerToRelocations; 
DWORD PointerToLinenumbers; 
WORD NumberOfRelocations; 
WORD NumberOfLinenumbers; 
DWORD Characteristics; 
) IMAGE SECTION HEADER, *PIMAGE SECTION HEADER; 
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Un mot à propos de le terminologie: PointerToRawData est appelé «Offset» dans 
Hiew et VirtualAddress est appelé «RVA » ici. 


-rdata — section de données en lecture seule (read-only) 


Les chaines sont généralement situées ici (car elles ont le type const char*), ainsi 
que d'autres variables marquées comme const, les noms des fonctions importées. 


Voir aussi: 3.3 on page 596. 


Relocs (relocalisation) 


AKA FIXUP-s (au moins dans Hiew). 


Elles sont aussi présentes dans presque tous les formats de fichiers exécutables ?!. 
Les exceptions sont les bibliothéques dynamiques partagées compilées avec PIC, ou 
tout autre code PIC. 


À quoi servent-elles? 


Évidemment, les modules peuvent étre chargés à différentes adresse de base, mais 
comment traiter les variables globales, par exemple? Elles doivent étre accédées 


22MSDN 
30MSDN 
31Méme dans les fichiers .exe pour MS-DOS 
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par adresse. Une solution est le code indépendant de la position (6.4.1 on page 974). 
Mais ce n'est pas toujours pratique. 


C'est pourquoi une table des relocalisations est présente. Elle contient les adresses 
des points qui doivent étre corrigés en cas de chargement à une adresse de base 
différente. 


Par exemple, il y a une variable globale à l'adresse 0x410000 et voici comment elle 
est accédée: 


A1 00 00 41 00 mov eax, [000410000] 


L'adresse de base du module est 0x400000, le RVA de la variable globale est 0x10000. 


Si le module est chargé à l'adresse de base 0x500000, l'adresse réelle de la variable 
globale doit étre 0x510000. 


Comme nous pouvons le voir, l'adresse de la variable est encodée dans l'instruction 
MOV, aprés l'octet OxAT. 


C'est pourquoi l'adresse des 4 octets aprés OxAl est écrite dans la table de relocali- 
sations. 


Si le module est chargé à une adresse de base différente, le chargeur de l'OS parcourt 
toutes les adresses dans la table, trouve chaque mot de 32-bit vers lequel elles 
pointent, soustrait l'adresse de base d'origine (nous obtenons le RVA ici), et ajoute 
la nouvelle adresse de base. 


Si un module est chargé à son adresse de base originale, rien ne se passe. 
Toutes les variables globales sont traitées ainsi. 


Relocs peut avoir différent types, toutefois, dans Windows pour processeurs x86, le 
type est généralement 
IMAGE REL BASED HIGHLOW. 


Á propos, les relocs sont plus foncés dans Hiew, par exemple: fig.1.21. (vous devez 
éviter ces octets lors d'un patch.) 


OllyDbg souligne les endroits en mémoire oü sont appliqués les relocs, par exemple: 
fig.1.52. 


Exports et imports 


Comme nous le savons, tout programme exécutable doit utiliser les services de l'OS 
et autres bibliothéques d'une maniére ou d'une autre. 


On peut dire que les fonctions d'un module (en général DLL) doivent étre reliées aux 
points de leur appel dans les autres modules (fichier .exe ou autre DLL). 


Pour cela, chaque DLL a une table d'«exports », qui consiste en les fonctions plus 
leur adresse dans le module. 


Et chaque fichier .exe ou DLL posséde des «imports », une table des fonctions re- 
quises pour l'exécution incluant une liste des noms de DLL. 
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Aprés le chargement du fichier .exe principal, le chargeur de l'OS traite la table des 
imports: il charge les fichiers DLL additionnels, trouve les noms des fonctions parmi 
les exports des DLL et écrit leur adresse dans le module IAT de l'.exe principal. 


Comme on le voit, pendant le chargement, le chargeur doit comparer de nombreux 
noms de fonctions, mais la comparaison des chaines n'est pas une procédure trés 
rapide, donc il y a un support pour «ordinaux » ou «hints », qui sont les numéros de 
fonctions stockés dans une table au lieu de leurs noms. 


C'est ainsi qu'elles peuvent étre localisées plus rapidement lors du chargement 
d'une DLL. Les ordinaux sont toujours présents dans la table d'«export ». 


Par exemple, un programme utilisant la bibliothéque MFC?? charge en général mfc*.dll 
par ordinaux, et dans un programme n'ayant aucun nom de fonction MFC dans INT. 


Lors du chargement d'un tel programme dans IDA, il va demander le chemin vers 
les fichiers mfc*.dll, afin de déterminer le nom des fonctions. 


Si vous ne donnez pas le chemin vers ces DLLs à IDA, il y aura mfc80 123 à la place 
des noms de fonctions. 


Section d'imports 


Souvent, une section séparée est allouée pour la table d'imports et tout ce qui y est 
relatif (avec un nom comme .idata), toutefois, ce n'est pas une règle stricte. 


Les imports sont un sujet prétant à confusion à cause de la terminologie confuse. 
Essayons de regrouper toutes les informations au méme endroit. 


32Microsoft Foundation Classes 
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IMAGE IMPORT DESCRIPTOR for kernel32.dll 


OriginalFirst Thunk 
TimeDateStamp = 0 
ForwarderChain = 0 
Name 
FirstT hunk 


IMAGE IMPORT DESCRIPTOR for user32.dll 


OriginalFirst Thunk 
TimeDateStamp = 0 
ForwarderChain = 0 
Name 

FirstT hunk 


E NULL IMAGE_IMPORT_DESCRIPTOR 


OriginalFirstThunk = 0 
TimeDateStamp = 0 


ForwarderChain = 0 
Name = 0 
FirstThunk = 0 


#1 (IMAGE. DIRECTORY. ENTRY. IMPORT) 


#5 IMAGE. DIRECTORY. ENTRY. BASERELOC) 


IMAGE REL BASED HIGHLOW, RVA of... 
IMAGE REL BASED HIGHLOW, RVA of ... 
IMAGE REL BASED HIGHLOW, RVA of ... 


IMAGE REL BASED HIGHLOW, RVA of ... 


IMAGE REL BASED HIGHLOW, RVA of ... 


OriginalFirstT hunk for kernel32.dll 


FirstThunk for kernel32.dll 


(These values are set by loader) 
#1 imp CreateFileA 

$2 imp GetFileSize 

#3 imp Sleep 
#4 imp WriteFile 


FirstThunk for user32.dll 


AAA) 
push arguments... 
call CreateFileA 


Afr 15 xx xx xx xx call imp GetFileSize 


/ 


FF 25 xx xx xx xx jmp imp Sleep 
FF 25 xx xx xx xx jmp imp WriteFile 


Fig. 6.1: Un schéma qui regroupe toutes les structures concernant les imports d'un 


fichier PE 


La structure principale est le tableau IMAGE IMPORT DESCRIPTOR, qui comprend un 


élément pour chaque DLL importée. 


Chaque élément contient l'adresse RVA de la chaîne de texte (nom de la DLL) (Name). 


OriginalFirstThunk est l'adresse RVA de la table INT. C'est un tableau d'adresses RVA, 
qui pointe chacune sur une chaîne de texte avec le nom d'une fonction. Chaque 
chaîne est préfixée par un entier 16-bit («hint »)—«ordinal » de la fonction. 


Pendant le chargement, s'il est possible de trouver une fonction par ordinal, la com- 


993 


paraison de chaínes n'a pas lieu. Le tableau est terminé par zéro. 


Il y a aussi un pointeur sur la table IAT appelé FirstThunk, qui est juste l'adresse RVA 
de l'endroit oü le chargeur écrit l'adresse résolue de la fonction. 


Les endroits oü le chargeur écrit les adresses sont marqués par IDA comme ceci: 
. imp CreateFileA, etc. 


Il y a au moins deux facons d'utiliser les adresses écrites par le chargeur. 


e Le code aura des instructions comme call imp CreateFileA, et puisque le 
champ avec l'adresse de la fonction importée est en un certain sens une va- 
riable globale, l'adresse de l'instruction call (plus 1 ou 2) doit être ajoutée à 
la table de relocs, pour le cas oü le module est chargé à une adresse de base 
différente. 


Mais, évidemment, ceci augmente significativement la table de relocs. 


Car il peut y avoir un grand nombre d'appels aux fonctions importées dans le 
module. 


En outre, une grosse table de relocs ralenti le processus de chargement des 
modules. 


* Pour chaque fonction importée, il y a seulement un saut alloué, en utilisant l'ins- 
truction JMP ainsi qu'un reloc sur lui. De tel point sont aussi appelés «thunks ». 


Tous les appels aux fonction importées sont juste des instructions CALL au 
«thunk» correspondant. Dans ce cas, des relocs supplémentaires ne sont pas 
nécessaire car cex CALL-s ont des adresses relatives et ne doivent pas étre 
corrigés. 


Ces deux méthodes peuvent étre combinées. 


Il est possible que l'éditeur de liens créé des «thunk »s individuels si il n'y a pas trop 
d'appels à la fonction, mais ce n'est pas fait par défaut 


Á propos, le tableau d'adresses de fonction sur lequel pointe FirstThunk ne doit pas 
nécessairement se trouver dans la section IAT. Par exemple, j'ai écrit une fois l'utili- 
taire PE add import?? pour ajouter des imports à un fichier .exe existant. 


Quelques temps plus tót, dans une version précédente de cet utilitaire, à la place de 
la fonction que vous vouliez substituer par un appel à une autre DLL, mon utilitaire 
écrivait le code suivant: 


MOV EAX, [yourdll.dll!function] 
JMP EAX 


FirstThunk pointe sur la premiére instruction. En d'autres mots, en chargeant yourdll.dll, 
le chargeur écrit l'adresse de la fonction function juste aprés le code. 


Il est à noter qu'une section de code est en général protégée contre l'écriture, donc 
mon utilitaire ajoute le flag 


33yurichev.com 
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IMAGE_SCN_MEM_WRITE pour la section de code. Autrement, le programme plante- 
rait pendant le chargement avec le code d'erreur 5 (access denied). 


On pourrait demander: pourrais-je fournir à un programme un ensemble de fichiers 
DLL qui n'est pas supposé changer (incluant les adresses des fonctions DLL), est-il 
possible d'accélérer le processus de chargement? 


Oui, il est possible d'écrire les adresses des fonctions qui doivent étre importées en 
avance dans le tableau FirstThunk. 
Le champ Timestamp est présent dans la structure IMAGE IMPORT. DESCRIPTOR. 


Si une valeur est présente ici, alors le loader compare cette valeur avec la date et 
l'heure du fichier DLL. 


Si les valeurs sont égales, alors le loader ne fait rien, et le processus de chargement 
peut étre plus rapide. Ceci est appelé «old-style binding » ?^. 


L'utilitaire BIND.EXE dans le SDK est fait pour ca. Pour accélérer le chargement de 
votre programme, Matt Pietrek dans Matt Pietrek, An In-Depth Look into the Win32 
Portable Executable File Format, (2002)]°°, suggère de faire le binding juste après 
l'installation de votre programme sur l'ordinateur de l'utilisateur final. 


Les packeurs/chiffreurs de fichier PE peuvent également compresser/chiffrer la table 
des imports. 


Dans ce cas, le loader de Windows, bien sür, ne va pas charger les DLLs nécessaires. 


Par conséquent, le packeur/chiffreur fait cela lui méme, avec l'aide des fonctions 
LoadLibrary() et GetProcAddress(). 


C'est pourquoi ces deux fonctions sont souvent présentes dans l'IAT des fichiers pa- 
Ckés. 

Dans les DLLs standards de l'installation de Windows, IAT es souvent situé juste 
aprés le début du fichier PE. Supposément, c'est fait par soucis d'optimisation. 


Pendant le chargement, le fichier .exe n'est pas chargé dans la mémoire d'un seul 
coup (rappelez-vous ces fichiers d'installation énormes qui sont démarrés de facon 
douteusement rapide), ils sont «mappés », et chargés en mémoire par parties lors- 
qu'elles sont accédées. 


Les développeurs de Microsoft ont sürement décidé que ca serait plus rapide. 


Ressources 


Les ressources dans un fichier PE sont seulement un ensemble d'icónes, d'images, 
de chaînes de texte, de descriptions de boîtes de dialogues. 


Peut-étre qu'elles ont été séparées du code principal afin de pouvoir étre multilingue, 
et il est plus simple de prendre du texte ou une image pour la langue qui est définie 


34MSDN. Il y a aussi le «new-style binding ». 
35Aussi disponible en http://msdn.microsoft.com/en-us/magazine/bb985992 .aspx 
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dans l'OS. 


Par effet de bord, elles peuvent étre éditées facilement et sauvées dans le fichier 
exécutable, méme si on n'a pas de connaissance particuliére, en utilisant l'éditeur 
ResHack, par exemple (6.5.2). 


.NET 


Les programmes .NET ne sont pas compilés en code machine, mais dans un bytecode 
spécial. Strictement parlant, il y a du bytecode à la place du code x86 usuel dans le 
fichier .eexe, toutefois, le point d'entrée (OEP) point sur un petit fragment de code 
x86: 


jmp mscoree.dll! CorExeMain 


Le loader de .NET se trouve dans mscoree.dil, qui traite le fichier PE. 


Il en était ainsi dans tous les OSes pre-Windows XP. Á partir de XP, le loader de l'OS 
est capable de détecter les fichiers .NET et le lance sans exécuter cette instruction 
JMP?6, 


TLS 


Cette section contient les données initialisées pour le TLS(6.2 on page 965) (si néces- 
saire). Lorsque qu'une nouvelle thread démarre, ses données TLS sont initialisées en 
utilisant les données de cette section. 


Á part ca, la spécification des fichiers PE fourni aussi l'initialisation de la section TLS, 
aussi appelée TLS callbacks. 


Si elles sont présentes, elles doivent étre appelées avant que le contróle ne soit 
passé au point d'entrée principal (OEP). 


Ceci est largement utilisé dans les packeurs/chiffreurs de fichiers PE. 


Outils 


* objdump (présent dans cygwin) pour afficher toutes les structures d'un fichier 
PE. 


* Hiew(7.1 on page 1029) comme éditeur. 
* pefile—bibliothéque-Python pour le traitement des fichiers PE ?7. 


* ResHack AKA Resource Hacker— éditeur de ressources?®. 


36MSDN 
37https://code.google.com/p/pefile/ 
38https://code.google.com/p/pefile/ 
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* PE add import??—outil simple pour ajouter des symboles à la table d'imports 
d'un exécutable au format PE. 


* PE patcher*%—outil simple pour patcher les exécutables PE. 


* PE search str refs^! —outil simple pour chercher une fonction dans un exécu- 
table PE qui utilise une certaine chaine de texte. 


Autres lectures 


* Daniel Pistelli—The .NET File Format 42 


6.5.3 Windows SEH 
Oublions MSVC 


Sous Windows, SEH concerne la gestion d'exceptions. Ce mécanisme est indépen- 
dant du langage de programmation et n'est en aucun cas spécifique ni à C++, ni à 
l'POO. 


Nous nous intéressons donc au SEH indépendamment du C++ et des extensions du 
langage dans MSVC. 


À chaque processus est associé une chaîne de gestionnaires SEH. A tout moment, 
chaque TIB référence le gestionnaire le plus récent de la chaîne. 


Dés qu'une exception intervient (division par zéro, violation d'accés mémoire, excep- 

tion explicitement déclenchée par le programme en appelant la fonction RaiseException() 
...), l'OS retrouve dans le TIB le gestionnaire le plus récemment déclaré et l'appelle. 

Il lui fourni l'état de la CPU (contenu des registres ...) tels qu'ils étaient lors du dé- 
clenchement de l'exception. 


Le gestionnaire examine le type de l'exception et décide de la traiter s'il la reconnaît. 
Sinon, il signale à l'OS qu'il passe la main et celui-ci appelle le prochain gestionnaire 
dans la chaine, et ainsi de suite jusqu'à ce qu'il trouve un gestionnaire qui soit ca- 
pable de la traiter. 


À la toute fin de la chaíne se trouve un gestionnaire standard qui affiche la fameuse 
boite de dialogue qui informe l'utilisateur que le processus va étre avorté. Ce dia- 
logue fournit quelques informations techniques au sujet de l'état de la CPU au mo- 
ment du crash, et propose de collecter des informations techniques qui seront en- 
voyées aux développeurs de Microsoft. 


39http://yurichev.com/PE add imports.html 

Wyurichev.com 

^lyurichev.com 
42http://www.codeproject.com/Articles/12585/The-NET- File-Format 
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crash.exe 


crash.exe has encountered a problem and needs to 
close. We are sorry for the inconvenience. 


Fig. 6.2: Windows XP 


Error Report Contents 


Fig. 6.3: Windows XP 
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UP crash.exe =151 xl 
|E || crash.exe has stopped working 

Windows can check online for a solution to the problem. 

> Check online for a solution and close the program 

+ Close the program 

+ Debug the program 


Problem signature: 
Problem Event Name: APPCRASH 
Application Name: crash.exe 
Application Version: 0.0.0.0 


Application Timestamp: 52d1973c 
Fault Module Name: crash.exe 
Fault Module Version: 0.0.0.0 

Fault Module Timestamp: 52d1973c 
Fycention Code: 0000005 


Fig. 6.4: Windows 7 


crash.exe has stopped working 


A problem caused the program to stop working correctly. 
Windows will close the program and notify you if a solution is 
available. 


Close program 


Fig. 6.5: Windows 8.1 


Historiquement, cette chaine de gestionnaires était connue sous l'appellation Dr. 
Watson ^. 


Certains développeurs ont eu l'idée d'écrire leur propre gestionnaire d'exceptions 
pour recevoir les informations relatives au crash. Ils enregistrent leur gestionnaire 
en appelant la fonction SetUnhandledExceptionFilter() qui sera alors appelée si 
l'OS ne trouve aucun autre gestionnaire qui souhaite gérer l'exception. 


Oracle RDBMS— en est un bon exemple qui sauvegarde un énorme fichier dump col- 
lectant toutes les informations possibles concernant la CPU et l'état de la mémoire. 


Écrivons notre propre gestionnaire d'exception. Cet exemple s'appuie sur celui de 
[Matt Pietrek, A Crash Course on the Depths of Win32™ Structured Exception Hand- 


^3Wikipédia 
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ling, (1997)]^^. Pour le compiler, il faut utiliser l'option SAFESEH : cl sehl.cpp 
/link /safeseh:no. Voustrouverez plus d'informations concernant SAFESEH à: MSDN. 


#include <windows.h> 
#include <stdio.h> 
DWORD new_value=1234; 
EXCEPTION DISPOSITION cdecl except_handler( 
struct EXCEPTION RECORD *ExceptionRecord, 
void * EstablisherFrame, 
struct CONTEXT *ContextRecord, 
void * DispatcherContext ) 
1 
unsigned i; 
printf ("%s\n", _ FUNCTION ); 
printf ("ExceptionRecord->ExceptionCode=0x%p\n", ExceptionRecord->,7 
V ExceptionCode); 
printf ("ExceptionRecord->ExceptionFlags=0x%p\n", ExceptionRecord-»7 
y ExceptionFlags); 
printf ("ExceptionRecord->ExceptionAddress=0x%p1n", ExceptionRecord” 
y ->ExceptionAddress) ; 
if (ExceptionRecord->ExceptionCode==0xE1223344) 
1 
printf ("That's for us\n"); 
// yes, we "handled" the exception 
return ExceptionContinueExecution; 
} 
else if (ExceptionRecord->ExceptionCode==EXCEPTION ACCESS VIOLATION 
S) 
1 
printf ("ContextRecord->Eax=0x%08X\n", ContextRecord->Eax); 
// will it be possible to 'fix' it? 
printf ("Trying to fix wrong pointer address\n"); 
ContextRecord->Eax=(DWORD)&new value; 
// yes, we "handled" the exception 
return ExceptionContinueExecution; 
} 
else 
{ 
printf ("We do not handle this\n"); 
// someone else's problem 
return ExceptionContinueSearch; 
}; 
} 
int main() 
1 
DWORD handler = (DWORD)except_handler; // take a pointer to our 
handler 


44 Aussi disponible en http: //www.microsoft.com/msj/0197/Exception/Exception.aspx 
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// install exception handler 


asm 
1 // make EXCEPTION REGISTRATION 
record: 
push handler // address of handler function 
push FS: [0] // address of previous handler 
mov FS: [0] ,ESP // add new EXECEPTION REGISTRATION 
} 


RaiseException (0xE1223344, 0, 0, NULL); 


// now do something very bad 
int* ptr=NULL; 

int val=0; 

val=*ptr; 

printf ("val=%d\n", val); 


// deinstall exception handler 


asm 
{ // remove our EXECEPTION REGISTRATION 
record 
mov eax, [ESP] // get pointer to previous record 
mov FS: [0], EAX // install previous record 
add esp, 8 // clean our EXECEPTION REGISTRATION 
off stack 
} 
return 0; 


En environnement win32, le registre de segment FS: contient l'adresse du TIB. 


Le tout premier élément de la structure TIB est un pointeur sur le premier gestion- 
naire de la chaîne de traitement des exceptions. Nous le sauvegardons sur la pile et 
remplaçons la valeur par celle de notre propre gestionnaire. La structure est du type 
_EXCEPTION REGISTRATION. ll s'agit d'une simple liste chainée dont les éléments 
sont conservés sur la pile. 


Listing 6.22 : MSVC/VC/crt/src/exsup.inc 


. EXCEPTION REGISTRATION struc 
prev dd ? 
handler dd ? 

. EXCEPTION REGISTRATION ends 


Le champ «handler» contient l'adresse du gestionnaire et le champ «prev » celle de 
l'enregistrement suivant dans la chaîne. Le dernier enregistrement contient la valeur 
OxFFFFFFFF (-1) dans son champ «prev ». 
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TIB 


+0: except list 


Prev=OxFFFFFFFF 


Gestionnaire d’ex- 
ception 


andl Gestionnaire d’ex- 
ange ception 


endi Gestionnaire d'ex- 
ange ception 


Une fois notre gestionnaire installé, nous invoquons la fonction RaiseException() 
^5. || s'agit d'une exception utilisateur. Le gestionnaire vérifie le code. Si le code est 
égal à 0xE1223344, il retourne la valeur ExceptionContinueExecution qui signifie 
que le gestionnaire a corrigé le contenu de la structure passée en paramétre qui 
décrit l'état de la CPU. La modification concerne généralement les registres EIP/ESP. 
L'OS peut alors reprendre l'exécution du thread. 


Si vous modifiez légérement le code pour que le gestionnaire retourne la valeur 
ExceptionContinueSearch, l'OS appellera les gestionnaires suivants dans la liste. Il 
est peu probable que l'un d'eux sache la gérer puisqu'aucun d'eux ne la comprend, 
ni ne connaît le code exception. Vous verrez donc apparaître la boîte de dialogue 
Windows précurseur du crash. 


Quelles sont les différences entre les exceptions systéme et les exceptions utilisa- 
teur? Les exceptions systéme sont listées ci-dessous: 
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as defined in WinBase.h as defined in ntstatus.h value 

EXCEPTION_ACCESS VIOLATION STATUS_ACCESS VIOLATION 0xC0000005 
EXCEPTION_DATATYPE_MISALIGNMENT STATUS_DATATYPE_MISALIGNMENT 0x80000002 
EXCEPTION_BREAKPOINT STATUS BREAKPOINT 0x80000003 
EXCEPTION SINGLE STEP STATUS SINGLE STEP 0x80000004 
EXCEPTION ARRAY BOUNDS EXCEEDED STATUS ARRAY BOUNDS EXCEEDED 0xC000008C 
EXCEPTION FLT DENORMAL OPERAND STATUS FLOAT DENORMAL OPERAND 0xC000008D 
EXCEPTION_FLT_DIVIDE_BY_ZERO STATUS FLOAT DIVIDE BY ZERO 0xC000008E 
EXCEPTION FLT INEXACT. RESULT STATUS FLOAT INEXACT RESULT 0xC000008F 
EXCEPTION_FLT_INVALID_OPERATION STATUS_FLOAT_INVALID_OPERATION 0xC0000090 
EXCEPTION FLT OVERFLOW STATUS FLOAT OVERFLOW 0xC0000091 
EXCEPTION FLT STACK CHECK STATUS FLOAT STACK CHECK 0xC0000092 
EXCEPTION FLT UNDERFLOW STATUS FLOAT UNDERFLOW 0xC0000093 
EXCEPTION INT DIVIDE BY ZERO STATUS INTEGER DIVIDE BY ZERO 0xC0000094 
EXCEPTION INT OVERFLOW STATUS INTEGER OVERFLOW 0xC0000095 
EXCEPTION PRIV INSTRUCTION STATUS PRIVILEGED INSTRUCTION 0xC0000096 
EXCEPTION IN PAGE ERROR STATUS IN PAGE ERROR 0xC0000006 
EXCEPTION ILLEGAL INSTRUCTION STATUS ILLEGAL INSTRUCTION 0xC000001D 
EXCEPTION NONCONTINUABLE EXCEPTION | STATUS NONCONTINUABLE EXCEPTION | 0xC0000025 
EXCEPTION STACK OVERFLOW STATUS STACK OVERFLOW OxCO00000FD 
EXCEPTION_INVALID_DISPOSITION STATUS INVALID DISPOSITION 0xC0000026 
EXCEPTION GUARD PAGE STATUS GUARD PAGE VIOLATION 0x80000001 
EXCEPTION INVALID HANDLE STATUS INVALID HANDLE 0xC0000008 
EXCEPTION POSSIBLE DEADLOCK STATUS POSSIBLE DEADLOCK 0xC0000194 
CONTROL C EXIT STATUS CONTROL C EXIT 0xC000013A 


Le code de chaque exception se décompose comme suit: 


31 29 28 27 


16 15 


S UlO Facility code 


Error code 


S est un code status de base: 11—erreur; 10—warning; 01—information; 00—succés. 


U—lorsqu’il s'agit d'un code utilisateur. 


Voici pourquoi nous choisissons le code 0xE1223344—E:6 (11105) OxE (1110b) qui 
signifie 1) qu'il s'agit d'une exception utilisateur; 2) qu'il s'agit d'une erreur. 


Pour étre honnéte, l'exemple fonctionne 


aussi bien sans ces bits de poids fort. 


Tentons maintenant de lire la valeur à l'adresse mémoire O. 


Bien entendu, dans win32 il n'existe rien à cette adresse, ce qui déclenche une 


exception. 


Le premier gestionnaire à être invoqué est le vôtre. Il reconnait l'exception car il 
compare le code avec celui de la constante EXCEPTION ACCESS VIOLATION. 


Le code qui lit la mémoire à l'adresse 0 ressemble à ceci: 


Listing 6.23 : MSVC 2010 


xor 


eax, eax 
mov eax, DWORD PTR [eax] 
push eax 

push OFFSET msg 


; exception will occur here 
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call _ printf 
add esp, 8 


Serait-il possible de corriger cette erreur «au vol» afin de continuer l'exécution du 
programme? 


Notre gestionnaire d'exception peut modifier la valeur du registre EAX puis laisser 
l'OS exécuter de nouveau l'instruction fautive. C'est ce que nous faisons et la raison 
pour laquelle printf() affiche 1234. Lorsque notre gestionnaire a fini son travail, la 
valeur de EAX n'est plus 0 mais l'adresse de la variable globale new value. L'exécu- 
tion du programme se poursuit donc. 


Voici ce qui se passe: le gestionnaire mémoire de la CPU signale une erreur, la CPU 
suspend le thread, trouve le gestionnaire d'exception dans le noyau Windows, lequel 
à son tour appelle les gestionnaires de la chaine SEH un par un. 


Nous utilisons ici le compilateur MSVC 2010. Bien entendu, il n'y a aucune garantie 
que celui-ci décide d'utiliser le registre EAX pour conserver la valeur du pointeur. 


Le truc du remplacement du contenu du registre n'est qu'une illustration de ce que 
peut étre le fonctionnement interne des SEH. En pratique, il est trés rare qu'il soit 
utilisé pour corriger «on-the-fly » une erreur. 


Pourquoi les enregistrements SEH sont-ils conservés directement sur la pile et non 
pas à un autre endroit? 


L'explication la plus plausible est que l'OS n'a ainsi pas besoin de libérer l'espace 
qu'ils utilisent. Ces enregistrements sont automatiquement supprimés lorsque la 
fonction se termine. C'est un peu comme la fonction alloca() : (1.9.2 on page 49). 


Retour à MSVC 


Microsoft a ajouté un mécanisme non standard de gestion d'exceptions à MSVC^? es- 
sentiellement à l'usage des programmeurs C. Ce mécanisme est totalement distinct 
de celui définit par le standard ISO du langage C++. 


_try 
{ 
} 


__except(filter code) 


handler code 


À la place du gestionnaire d'exception, on peut trouver un block «Finally » : 


. try 


a 
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_ finally 
1 


} 


Le code de filtrage est une expression. L'évaluation de celle-ci permet de définir si 
le gestionnaire reconnait l'exception qui a été déclenchée. 


Si votre filtre est trop complexe pour tenir dans une seule expression, une fonction 
de filtrage séparée peut étre définie. 


Il existe de nombreuses constructions de ce type dans le noyau Windows. En voi- 
ci quelques exemples (WRK) : 


Listing 6.24 : WRK-v1.2/base/ntos/ob/obwait.c 


try { 


KeReleaseMutant( (PKMUTANT)SignalObject, 
MUTANT INCREMENT, 
FALSE, 
TRUE ); 


) except((GetExceptionCode () == STATUS ABANDONED || 
GetExceptionCode () == STATUS MUTANT NOT OWNED)? 
EXCEPTION EXECUTE HANDLER : 
EXCEPTION CONTINUE SEARCH) { 
Status = GetExceptionCode(); 


goto WaitExit; 


Listing 6.25 : WRK-v1.2/base/ntos/cache/cachesub.c 


try { 


RtlCopyBytes( (PVOID)((PCHAR)CacheBuffer + PageOffset), 
UserBuffer, 
MorePages ? 
(PAGE SIZE - PageOffset) 
(ReceivedLength - PageOffset) ); 


) except( CcCopyReadExceptionFilter( GetExceptionInformation(), 
&Status ) ) 1 


Voici aussi un exemple de code de filtrage: 


Listing 6.26 : WRK-v1.2/base/ntos/cache/copysup.c 


LONG 

CcCopyReadExceptionFilter ( 
IN PEXCEPTION POINTERS ExceptionPointer, 
IN PNTSTATUS ExceptionCode 
) 
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[++ 

Routine Description: 
This routine serves as an exception filter and has the special job of 
extracting the "real" I/O error when Mm raises STATUS IN PAGE ERROR 
beneath us. 


Arguments: 


ExceptionPointer - A pointer to the exception record that contains 
the real Io Status. 


ExceptionCode - A pointer to an NTSTATUS that is to receive the real 
status. 


Return Value: 


EXCEPTION EXECUTE HANDLER 


--*/ 

{ 
*ExceptionCode = ExceptionPointer->ExceptionRecord->ExceptionCode; 
if ( (*ExceptionCode == STATUS IN PAGE ERROR) && 

(ExceptionPointer->ExceptionRecord->NumberParameters >= 3) ) { 
*ExceptionCode = (NTSTATUS) ExceptionPointer->ExceptionRecord->/ 

V ExceptionInformation[2]; 
} 
ASSERT( !NT SUCCESS(*ExceptionCode) ); 
return EXCEPTION EXECUTE HANDLER; 

l 


En interne, SEH est une extension du mécanisme de gestion des exceptions implé- 
menté par l'OS. La fonction de gestion d'exceptions est except handler3 (pour 
SEH3) ou except handler4 (pour SEHA). 


Le code de ce gestionnaire est propre à MSVC et est situé dans ses librairies, ou dans 
msvcr*.dll. Il est essentiel de comprendre que SEH est purement lié à MSVC. 


D'autres compilateurs win32 peuvent choisir un modéle totalement différent. 
SEH3 


SEH3 est géré par la fonction except handler3.ll ajoute à la structure EXCEPTION REGISTRATION 
un pointeur vers une scope table et une variable previous try level. SEH4 de son có- 
té ajoute 4 valeurs à la structure scope table pour la gestion des dépassements de 
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buffer. 


La structure scope table est un ensemble de pointeurs vers les blocs de code du 


filtre et du gestionnaire de chaque niveau try/except imbriqué. 


TIB Stack 


+0: except list 


scope table 


OxFFFFFFFF (-1) 
fonction de filtrage 
handler/finaliseur 


A ; scope table 
fonction de filtrage 
handler/finaliseur BEEN 


fonction de filtrage 
handler/finaliseur 


.. en savoir plus ... 


Il est essentiel de comprendre que l'OS ne se préoccupe que des champs prev/handle 


et de rien d'autre. 


Les autres champs sont exploités par la fonction except handler3, de méme que 
le contenu de la structure scope table afin de décider quel gestionnaire exécuter et 


quand. 


Le code source de la fonction except handler3 n'est pas public. 


Cependant, le systéme d'exploitation Sanos, posséde un mode de compatibilité win32. 
Celui-ci ré-implémente les mémes fonctions d'une maniére quasi équivalente à celle 
de Windows *”. On trouve une autre ré-implémentation dans Wine“ ainsi que dans 


47https://code.google.com/p/sanos/source/browse/src/win32/msvcrt/except.c 
48GitHub 


Gestionnaire d’ex- 
ception 


Gestionnaire d’ex- 
ception 


_except_handler3 
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ReactOS^?, 


Lorsque le champ filter est un pointeur NULL, le champ handler est un pointeur 
vers un bloc de code finally. 


Au cours de l'exécution, la valeur du champ previous try level change. 


Ceci permet à la fonction except handler3 de connaître le niveau d'imbrication et 
donc de savoir quelle entrée de la table scope table utiliser en cas d'exception. 


SEH3: exemple de bloc try/except 


#include <stdio.h> 
#include <windows.h> 
#include <excpt.h> 


int main() 
{ 
int* p = NULL; 
_try 
1 
printf("hello #1!\n"); 
*p = 13; // causes an access violation exception; 
printf("hello #2!\n"); 
} 


_ except (GetExceptionCode()==EXCEPTION ACCESS VIOLATION ? 
EXCEPTION EXECUTE HANDLER : EXCEPTION CONTINUE SEARCH) 


{ 
printf("access violation, can't recover\n"); 

} 

} 
Listing 6.27 : MSVC 2003 

$SG74605 DB ‘hello #1!', OaH, OOH 
$SG74606 DB ‘hello #2!', OaH, OOH 
$SG74608 DB ‘access violation, can''t recover', OaH, 00H 
_DATA ENDS 
; scope table: 
CONST SEGMENT 
$174622 DD OffffffffH ; previous try level 


DD FLAT:$L74617 ; filter 
DD FLAT:$L74618 ; handler 


CONST ENDS 

_ TEXT SEGMENT 

$174621 = -32 ; size = 4 

_p$ = -28 ; size = 4 

. S$SEHRec$ = -24 ; size = 24 
_main PROC NEAR 


49http://doxygen. reactos.org/d4/df2/lib 2sdk 2crt 2except 2except 8c source.html 
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push ebp 
mov ebp, esp 
push -1 ; previous try level 
push OFFSET FLAT:$T74622 ; Scope table 
push OFFSET FLAT: except handler3 ; handler 
mov eax, DWORD PTR fs: except list 
push eax ; prev 
mov DWORD PTR fs: except list, esp 
add esp, -16 
; 3 registers to be saved: 
push ebx 
push esi 
push edi 
mov DWORD PTR  $SEHRec$[ebp], esp 
mov DWORD PTR p$[ebp], 0 
mov DWORD PTR $SEHRec$[ebp«20], 0 ; previous try level 
push OFFSET FLAT:$SG74605 ; 'hello +1!' 
call printf 
add esp, 4 
mov eax, DWORD PTR _p$[ebp] 
mov DWORD PTR [eax], 13 
push OFFSET FLAT: $SG74606 ; ‘hello #2!' 
call printf 
add esp, 4 
mov DWORD PTR _ $SEHRec$[ebp+20], -1 ; previous try level 
jmp SHORT $L74616 
; filter code: 
$L74617: 
$L74627: 
mov ecx, DWORD PTR $SEHRec$[ebp+4] 
mov edx, DWORD PTR [ecx] 
mov eax, DWORD PTR [edx] 
mov DWORD PTR $T74621[ebp], eax 
mov eax, DWORD PTR $T74621[ebp] 
sub eax, -1073741819; c0000005H 
neg eax 
sbb eax, eax 
inc eax 
$L74619: 
$L74626: 
ret 0 


; handler code: 


$L74618: 
mov 
push 
call 
add 
mov 
to -1 

$L74616: 
xor 
mov 


esp, DWORD PTR $SEHRec$[ebp] 

OFFSET FLAT:$SG74608 ; 'access violation, can''t recover' 

| printf 

esp, 4 

DWORD PTR _ $SEHRec$[ebp+20], -1 ; setting previous try level back 


eax, eax 
ecx, DWORD PTR $SEHRec$[ebp+8] 
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mov DWORD PTR fs: except list, ecx 


pop edi 
pop esi 
pop ebx 
mov esp, ebp 
pop ebp 
ret 0 
_main ENDP 
_TEXT ENDS 
END 


Nous voyons ici la maniére dont le bloc SEH est construit sur la pile. La structure 
scope table est présente dans le segment CONST du programme— ce qui est normal 
puisque son contenu n'a jamais besoin d'étre changé. Un point intéressant est la 
manière dont la valeur de la variable previous try level évolue. Sa valeur initiale est 
OxFFFFFFFF (-1). L'entrée dans le bloc try débute par l'écriture de la valeur O dans 
la variable. La sortie du bloc try est marquée par la restauration de la valeur -1. 
Nous voyons également l'adresse du bloc de filtrage et de celui du gestionnaire. 


Nous pouvons donc observer facilement la présence de blocs try/except dans la fonc- 
tion. 


Le code d'initialisation des structures SEH dans le prologue de la fonction peut étre 
partagé par de nombreuses fonctions. Le compilateur choisi donc parfois d'insérer 
dans le prologue d'une fonction un appel à la fonction SEH prolog() qui assure cette 
initialisation. 

Le code de nettoyage des structures SEH se trouve quant à lui dans la fonction 
SEH epilog(). 


Tentons d'exécuter cet exemple dans tracer : 


tracer.exe -l:2.exe --dump-seh 


Listing 6.28 : tracer.exe output 


EXCEPTION ACCESS VIOLATION at 2.exe!main+0x44 (0x401054) 7 
y ExceptionInformation[0]=1 
EAX=0x00000000 EBX=0x7efde000 ECX-0x0040cbc8 EDX-0x0008e3c8 
ESI=0x00001db1 EDI=0x00000000 EBP=0x0018feac ESP=0x0018fe80 
EIP-0x00401054 
FLAGS-AF IF RF 
* SEH frame at 0x18fe9c prev=0x18ff78 handler=0x401204 (2.exe! 7 
V except handler3) 
SEH3 frame. previous trylevel=0 
scopetable entry[0]. previous try level=-1, filter=0x401070 (2.exe!main+07 
y X60) handler=0x401088 (2.exe!main+0x78) 
* SEH frame at 0x18ff78 prev=0x18ffc4 handler=0x401204 (2.exe! 7 
y except handler3) 
SEH3 frame. previous trylevel=0 
scopetable entry[0]. previous try level=-1, filter=0x401531 (2.exe!7 
y mainCRTStartup+0x18d) handler=0x401545 (2.exe!mainCRTStartup+0x1lal) 


1010 


* SEH frame at 0x18ffc4 prev=0x18ffe4 handler=0x771f71f5 (ntdll.dll! 2 
& — except handler4) 
SEH4 frame. previous trylevel=0 
SEH4 header: GSCookie0ffset=0xfffffffe GSCookieXOROffsetz0x0 
EHCookie0ffset=0xffffffcc EHCookieXOROffset=0x0 
scopetable entry[0]. previous try level=-2, filter=0x771f74d0 (ntdll.dll!^ 
G_ safe se handler table+0x20) handler=0x771f90eb (ntdll.dll!^ 
S _TppTerminateProcess@4+0x43 ) 
* SEH frame at 0x18ffe4 prev=0xffffffff handler=0x77247428 (ntdll.dll! 2 
\ _FinalExceptionHandler@16) 


Nous constatons que la chaine SEH est constituée de 4 gestionnaires. 


Le deux premiers sont situés dans le code de notre exemple. Deux? Mais nous 
n’en avons défini qu'un! Effectivement, mais un second a été initialisé dans la fonc- 
tion mainCRTStartup() du CRT. Il semble que celui-ci gère au moins les exceptions 
FPU. Son code source figure dans le fichier crt/src/winxfltr.c fournit avec l'ins- 
tallation de MSVC. 


Le troisième est le gestionnaire SEH4 dans ntdll.dll. Le quatrième n'est pas lié a 
MSVC et se situe dans ntdil.dil. Son nom suffit à en décrire l'utilité. 


Comme vous le constatez, nous avons 3 types de gestionnaire dans la méme chaíne: 


L'un n'a rien à voir avec MSVC (le dernier) et deux autres sont liés à MSVC: SEH3 et 
SEH4. 


SEH3: exemple de deux blocs try/except 


#include <stdio.h> 
#include <windows.h> 
#include <excpt.h> 


int filter user exceptions (unsigned int code, struct EXCEPTION POINTERS *2 


V ep) 
1 
printf("in filter. code=0x%08X1n", code); 
if (code == 0x112233) 
{ 
printf("yes, that is our exception\n"); 
return EXCEPTION EXECUTE HANDLER; 
} 
else 
{ 
printf("not our exception\n") ; 
return EXCEPTION CONTINUE SEARCH; 
F; 
} 
int main() 
1 


int* p = NULL; 
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) 


| e 
1 
} 


|. excep 
S GetEx 
1 
/ / 
/ / 
/ / 
pri 


printf ("hello!\n"); 

RaiseException (0x112233, 0, 0, NULL); 

printf ("0x112233 raised. now let's crash\n"); 

*p = 13; // causes an access violation exception; 


xcept (GetExceptionCode()==EXCEPTION ACCESS VIOLATION ? 
EXCEPTION EXECUTE HANDLER : EXCEPTION CONTINUE SEARCH) 


printf("access violation, can't recover\n"); 


t(filter user exceptions (GetExceptionCode(), Z 
ceptionInformation())) 


the filter user exceptions() function answering to the question 
"is this exception belongs to this block?" 

if yes, do the follow: 

ntf("user exception caught\n") ; 


Nous avons 


maintenant deux blocs try. La structure scope table posséde donc deux 


entrées, une pour chaque bloc. La valeur de Previous try level change selon que 
l'exécution entre ou sort des blocs try. 


Listing 6.29 : MSVC 2003 


$SG74606 DB 
$5G74608 DB 
$5674610 DB 
$5674617 DB 
$5674619 DB 
$5674621 DB 
$5674623 DB 


_code$ = 8 

_ep$ = 12 

_filter_use 
push 
mov 
mov 
push 
push 
call 
add 
cmp 
jne 
push 
call 
add 


‘in filter. code=0x%08X', OaH, OOH 

‘yes, that is our exception', OaH, 00H 

‘not our exception', 0aH, 00H 

'hello!', OaH, OOH 

'0x112233 raised. now let''s crash', OaH, 00H 
‘access violation, can''t recover', OaH, OOH 
‘user exception caught', 0aH, 00H 


; size = 4 
; size = 4 
r_exceptions PROC NEAR 
ebp 
ebp, esp 
eax, DWORD PTR _code$[ebp] 
eax 
OFFSET FLAT:$SG74606 ; ‘in filter. code=0x%08X' 
_printf 
esp, 8 
DWORD PTR code$[ebp], 1122867; 00112233H 


SHORT $L74607 

OFFSET FLAT:$SG74608 ; ‘yes, that is our exception’ 
_printf 

esp, 4 
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mov eax, 1 
jmp SHORT $L74605 
$L74607: 


push OFFSET FLAT:$SG74610 ; 'not our exception' 


call printf 
add esp, 4 


xor eax, eax 
$L74605: 

pop ebp 

ret 0 


filter user exceptions ENDP 


; Scope table: 

CONST SEGMENT 

$174644 DD OffffffffH 
DD FLAT:$L74634 
DD FLAT:$L74635 
DD 00H 
DD FLAT: $L74638 
DD FLAT: $L74639 

CONST ENDS 


$174643 = -36 ; size = 4 
$T74642 = -32 ; size = 4 
_p$ = -28 ; size = 4 
__$SEHRec$ = -24 ; size = 2 


main PROC NEAR 


previous try level for outer block 
outer block filter 
outer block handler 
previous try level for inner block 
inner block filter 
inner block handler 


push ebp 

mov ebp, esp 

push -] ; previous try level 

push OFFSET FLAT:$T74644 

push OFFSET FLAT: except handler3 
mov eax, DWORD PTR fs: except list 
push eax 

mov DWORD PTR fs: except list, esp 
add esp, -20 

push ebx 

push esi 

push edi 

mov DWORD PTR  $SEHRec$[ebp], esp 
mov DWORD PTR p$[ebp], 0 

mov DWORD PTR _ $SEHRec$[ebp+20], © ; outer try block entered. 


previous try level to 0 


mov 


DWORD PTR _ $SEHRec$[ebp+20], 1 ; inner try block entered. 


previous try level to 1 


push OFFSET FLAT:$5G74617 ; 'hello!' 
call _ printf 

add esp, 4 

push 0 

push 0 

push 0 

push 1122867 ; 00112233H 

call DWORD PTR imp RaiseException@16 


push 


OFFSET FLAT : $SG74619 ; '0x112233 raised. now let''s crash" 


set 


set 
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call 
add 
mov 
mov 
mov 


| printf 

esp, 4 

eax, DWORD PTR p$[ebp] 

DWORD PTR [eax], 13 

DWORD PTR _ $SEHRec$[ebp+20], © ; inner try block exited. set 


previous try level back to 0 


jmp 


SHORT $L74615 


; inner block filter: 


$L74638: 
$L74650: 
mov 
mov 
mov 
mov 
mov 
sub 
neg 
sbb 
inc 
$L74640: 
$L74648: 
ret 


ecx, DWORD PTR $SEHRec$[ebp+4] 
edx, DWORD PTR [ecx] 

eax, DWORD PTR [edx] 

DWORD PTR $T74643[ebp], eax 

eax, DWORD PTR $T74643[ebp] 

eax, -1073741819; c0000005H 

eax 

eax, eax 

eax 


0 


; inner block handler: 


$L74639: 
mov 
push 
call 
add 
mov 


esp, DWORD PTR  $SEHRec$[ebp] 

OFFSET FLAT:$SG74621 ; 'access violation, can''t recover' 

| printf 

esp, 4 

DWORD PTR  $SEHRec$[ebp«20], © ; inner try block exited. set 


previous try level back to 0 


$L74615: 
mov 


DWORD PTR _ $SEHRec$[ebp+20], -1 ; outer try block exited, set 


previous try level back to -1 


jmp 


SHORT $L74633 


; outer block filter: 


$L74634: 
$L74651: 
mov 
mov 
mov 
mov 
mov 
push 
mov 
push 
call 
add 
$L74636: 
$L74649: 
ret 


ecx, DWORD PTR $SEHRec$[ebp+4] 
edx, DWORD PTR [ecx] 

eax, DWORD PTR [edx] 

DWORD PTR $T74642[ebp], eax 

ecx, DWORD PTR $SEHRec$[ebp+4] 
ecx 

edx, DWORD PTR $T74642[ebp] 

edx 

filter user exceptions 

esp, 8 
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; outer block handler: 
$L74635: 
mov esp, DWORD PTR $SEHRec$[ebp] 
push OFFSET FLAT:$5G74623 ; ‘user exception caught’ 
call printf 
add esp, 4 
mov DWORD PTR $SEHRec$[ebp-20], -1 ; both try blocks exited. set 
previous try level back to -1 
$L74633: 
xor eax, eax 
mov ecx, DWORD PTR $SEHRec$[ebp-8] 
mov DWORD PTR fs: except list, ecx 


pop edi 
pop esi 
pop ebx 
mov esp, ebp 
pop ebp 
ret 0 
main ENDP 


Si nous positionnons un point d'arrét sur la fonction printf() qui est appelée par 
le gestionnaire, nous pouvons constater comment un nouveau gestionnaire SEH est 
ajouté. 


Il s'agit peut-étre d'un autre mécanisme interne de la gestion SEH. Nous constatons 
aussi que notre structure scope table contient 2 entrées. 


tracer.exe -1:3.exe bpx=3.exe!printf --dump-seh 


Listing 6.30 : tracer.exe output 


(0) 3.exe!printf 
EAX-0x0000001b EBX=0x00000000 ECX=0x0040cc58 EDX-0x0008e3c8 
ESI-0x00000000 EDI=0x00000000 EBP=0x0018f840 ESP-0x0018f838 
EIP=0x004011b6 
FLAGS=PF ZF IF 
* SEH frame at 0x18f88c prev=0x18fe9c handler=0x771db4ad (ntdll.dll! 2 
\ ExecuteHandler2@20+0x3a) 
* SEH frame at 0x18fe9c prev=0x18ff78 handler=0x4012e0 (3.exe! 7 
 except_handler3) 
SEH3 frame. previous trylevel=1 
scopetable entry[0]. previous try level=-1, filter=0x401120 (3.exe!main+0 
y xb0) handler=0x40113b (3.exe!main+0xcb) 
scopetable entry[1]. previous try level=0, filter=0x4010e8 (3.exe!main-40x787 
& ) handler=0x401100 (3.exe!main+0x90) 
* SEH frame at 0x18ff78 prev=0x18ffc4 handler=0x4012e0 (3.exe! 7 
Y except handler3) 
SEH3 frame. previous trylevel=0 
scopetable entry[0]. previous try level=-1, filter=0x40160d (3.exe! 7 
y mainCRTStartup+0x18d) handler=0x401621 (3.exe!mainCRTStartup+0xlal) 
* SEH frame at 0x18ffc4 prev=0x18ffe4 handler=0x771f71f5 (ntdll.dll! 7 
& — except handler4) 
SEH4 frame. previous trylevel=0 
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SEH4 header: GSCookie0ffset=0xfffffffe GSCookieXOROffset-0x0 
EHCookie0ffset=0xffffffcc EHCookieXOROf fset=0x0 
scopetable entry[0]. previous try level=-2, filter=0x771f74d0 (ntdll.dll! 2 
$ _safe_se handler table+0x20) handler=0x771f90eb (ntdll.dll!v 
S _TppTerminateProcess@4+0x43 ) 
* SEH frame at 0x18ffe4 prev=0xffffffff handler=0x77247428 (ntdll.dll! 7 
\ FinalExceptionHandler(16) 


SEH4 


Lors d'une attaque par dépassement de buffer (1.26.2 on page 350), l'adresse de 
la scope table peut étre modifiée. C’est pourquoi a partir de MSVC 2005 SEH3 a été 
amélioré vers SEH4 pour ajouter une protection contre ce type d'attaque. Le pointeur 
vers la structure scope table est désormais xored avec la valeur d'un security cookie. 
Par ailleurs, la structure scope table a été étendue avec une en-téte contenant deux 
pointeurs vers des security cookies. 


Chaque élément contient un offset dans la pile d'une valeur correspondant à: adresse 
du stack frame (EBP) xored avec la valeur du security cookie lui aussi situé sur la 
pile. 


Durant la gestion d'exception, l'intégrité de cette valeur est vérifiée. La valeur de 
chaque security cookie situé sur la pile est aléatoire. Une attaque à distance ne pour- 
ra donc pas la deviner. 


Avec SEHA, la valeur initiale de previous try level est de -2 et non de -1. 
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Stack 


. except list 


scope table 
OxFFFFFFFF (-1) esecurity cookie 
fonction de filtrage DU; 
= 
handler/finaliseur 


EBPesecurity_cookig 
fonction de filtrage 


handler/finaliseur 
fonction de filtrage 


handler/finaliseur 
ERLIIM 


Voici deux exemples compilés avec MSVC 2012 et SEH4: 


Listing 6.31 : MSVC 2012: exemple bloc try unique 


PrevzOxFFFFFFFF 


Gestionnaire d'ex- 
ception 


Gestionnaire d'ex- 
ception 


except handler4 


$SG85485 DB ‘hello #1!', OaH, 00H 
$SG85486 DB ‘hello #2!', OaH, 00H 
$SG85488 DB ‘access violation, can''t recover', OaH, 00H 
; scope table: 
xdata$x SEGMENT 
. Sehtable$ main DD OfffffffeH ; 6S Cookie Offset 
DD 00H ; GS Cookie XOR Offset 
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xdata$x 


-36 
_p$ = -32 
tv68 = -2 
__$SEHRec 
main 
push 
mov 
push 
push 
push 
mov 
push 
add 
push 
push 
push 
mov 
xor 
xor 
push 
lea 


OffffffccH ; EH Cookie Offset 
00H ; EH Cookie XOR Offset 
OfffffffeH ; previous try level 


FLAT : $LN12@main ; filter 
FLAT : $LN8@main  ; handler 


ENDS 
: size = 4 
: size = 4 
8 ; size = 4 
$ = -24 ; size = 24 
PROC 
ebp 
ebp, esp 
-2 


OFFSET  sehtable$ main 

OFFSET except handler4 

eax, DWORD PTR fs:0 

eax 

esp, -20 

ebx 

esi 

edi 

eax, DWORD PTR security cookie 

DWORD PTR _ $SEHRec$[ebp+16], eax ; xored pointer to scope table 
eax, ebp 

eax ; ebp ^ security cookie 
eax, DWORD PTR _ $SEHRec$[ebp+8] ; 


pointer to VC_EXCEPTION REGISTRATION RECORD 


mov 
mov 
mov 
mov 
push 
call 
add 
mov 
mov 
push 
call 
add 
mov 
jmp 


; filter: 

$LN7@main 

$LN12@mai 
mov 
mov 
mov 
mov 
cmp 
jne 
mov 


DWORD PTR fs:0, eax 

DWORD PTR _ $SEHRec$[ebp], esp 

DWORD PTR p$[ebp], 0 

DWORD PTR _ $SEHRec$[ebp+20], © ; previous try level 
OFFSET $5G85485 ; ‘hello #1!' 

| printf 

esp, 4 

eax, DWORD PTR p$[ebp] 

DWORD PTR [eax], 13 

OFFSET $5G85486 ; ‘hello #2!' 

| printf 

esp, 4 

DWORD PTR _ $SEHRec$[ebp+20], -2 ; previous try level 
SHORT $LN6@main 


n: 
ecx, DWORD PTR $SEHRec$[ebp+4] 
edx, DWORD PTR [ecx] 
eax, DWORD PTR [edx] 
DWORD PTR $T2[ebp], eax 
DWORD PTR $T2[ebp], -1073741819 ; c0000005H 
SHORT $LN4@main 
DWORD PTR tv68[ebp], 1 
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jmp SHORT $LN5@main 
$LN4@main: 
mov DWORD PTR tv68[ebp], 0 
$LN5@main: 
mov eax, DWORD PTR tv68[ebp] 
$LN9@main: 
$LN11@main: 
ret 0 
; handler: 
$LN8@main: 
mov esp, DWORD PTR _ $SEHRec$[ebp] 
push OFFSET $SG85488 ; ‘access violation, can''t recover' 
call printf 
add esp, 4 
mov DWORD PTR _ $SEHRec$[ebp+20], -2 ; previous try level 
$LN6@main: 
xor eax, eax 
mov ecx, DWORD PTR _ $SEHRec$[ebp+8] 
mov DWORD PTR fs:0, ecx 
pop ecx 
pop edi 
pop esi 
pop ebx 
mov esp, ebp 
pop ebp 
ret 0 
_Main ENDP 
Listing 6.32 : MSVC 2012: exemple de deux blocs try 
$SG85486 DB ‘in filter. code=0x%08X', OaH, OOH 
$SG85488 DB ‘yes, that is our exception’, OaH, 00H 
$5G85490 DB ‘not our exception’, OaH, 00H 
$5G85497 DB 'hello!', OaH, OOH 
$5G85499 DB '0x112233 raised. now let''s crash', OaH, 00H 
$SG85501 DB ‘access violation, can''t recover', OaH, OOH 
$5G85503 DB ‘user exception caught', OaH, OOH 
xdata$x SEGMENT 
. sehtable$ main DD OfffffffeH ; GS Cookie Offset 
DD 00H ; GS Cookie XOR Offset 
DD Of fffffc8H ; EH Cookie Offset 
DD 00H ; EH Cookie Offset 
DD OfffffffeH ; previous try level for outer block 
DD FLAT : $LN19@main ; outer block filter 
DD FLAT:$LN9Gmain ; outer block handler 
DD 00H ; previous try level for inner block 
DD FLAT : $LN18@main ; inner block filter 
DD FLAT:$LN13@main ; inner block handler 
xdata$x ENDS 
$T2 = -40 ; size = 4 
$T3 = -36 ; size = 4 
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_p$ = -32 ; size = 4 
tv72 = -28 ; size = 4 
. S$SEHRec$ = -24 ; size = 24 
_main PROC 
push ebp 
mov ebp, esp 
push -2 ; initial previous try level 
push OFFSET  sehtable$ main 
push OFFSET except handler4 
mov eax, DWORD PTR fs:0 
push eax ; prev 
add esp, -24 
push ebx 
push esi 
push edi 
mov eax, DWORD PTR security cookie 
xor DWORD PTR _ $SEHRec$[ebp+16], eax 
table 
xor eax, ebp 
push eax 
lea eax, DWORD PTR __ $SEHRec$[ebp+8] 


pointer to VC_EXCEPTION REGISTRATION RECORD 


mov 
mov 
mov 
mov 
setting 
mov 
setting 
push 
call 
add 
push 
push 
push 
push 
call 
push 
call 
add 
mov 
mov 
mov 


jmp 


DWORD PTR fs:0, eax 
DWORD PTR — $SEHRec$[ebp], esp 
DWORD PTR p$[ebp], 0 


; xored pointer to scope 


; ebp ^ security cookie 


DWORD PTR _ $SEHRec$[ebp+20], © ; entering outer try block, 


previous try level=0 


DWORD PTR _ $SEHRec$[ebp+20], 1 ; entering inner try block, 


previous try level=1 

OFFSET $5G85497 ; 'hello!' 

| printf 

esp, 4 

0 

0 

0 

1122867 ; 00112233H 

DWORD PTR imp RaiseException@16 
OFFSET $SG85499 ; '0x112233 raised. now let''s crash' 
| printf 

esp, 4 


eax, DWORD PTR _p$[ebp] 
DWORD PTR [eax], 13 


DWORD PTR _ $SEHRec$[ebp+20], © ; exiting inner try block, set 
previous try level back to 0 


SHORT $LN2@main 


; inner block filter: 


$LN12@main: 

$LN18@main: 
mov 
mov 
mov 
mov 
cmp 
jne 


ecx, DWORD PTR _ $SEHRec$[ebp+4] 
edx, DWORD PTR [ecx] 

eax, DWORD PTR [edx] 

DWORD PTR $T3[ebp], eax 


DWORD PTR $T3[ebp], -1073741819 ; c0000005H 


SHORT $LN5@main 
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mov DWORD PTR tv72[ebp], 1 

jmp SHORT $LN6@main 
$LN5@main: 

mov DWORD PTR tv72[ebp], 0 
$LN6@main: 

mov eax, DWORD PTR tv72[ebp] 
$LN14@main: 
$LN16@main: 

ret 0 


; inner block handler: 
$LN13@main: 
mov esp, DWORD PTR _ $SEHRec$[ebp] 
push OFFSET $SG85501 ; ‘access violation, can''t recover' 
call _ printf 
add esp, 4 
mov DWORD PTR _ $SEHRec$[ebp+20], © ; exiting inner try block, setting 
previous try level back to 0 
$LN2@main: 
mov DWORD PTR _ $SEHRec$[ebp+20], -2 ; exiting both blocks, setting 
previous try level back to -2 
jmp SHORT $LN7@main 


; outer block filter: 
$LN8@main: 
$LN19@main: 
mov ecx, DWORD PTR _ $SEHRec$[ebp+4] 
mov edx, DWORD PTR [ecx] 
mov eax, DWORD PTR [edx] 
mov DWORD PTR $T2[ebp], eax 
mov ecx, DWORD PTR _ $SEHRec$[ebp+4] 


push ecx 
mov edx, DWORD PTR $T2[ebp] 
push edx 
call filter user exceptions 
add esp, 8 

$LN10@main: 

$LN17@main: 
ret 0 


; outer block handler: 
$LN9@main: 
mov esp, DWORD PTR _ $SEHRec$[ebp] 
push OFFSET $5G85503 ; ‘user exception caught’ 
call printf 
add esp, 4 
mov DWORD PTR _ $SEHRec$[ebp+20], -2 ; exiting both blocks, setting 
previous try level back to -2 
$LN7@main: 
xor eax, eax 
mov ecx, DWORD PTR _ $SEHRec$[ebp+8] 
mov DWORD PTR fs:0, ecx 
pop ecx 
pop edi 
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pop esi 
pop ebx 
mov esp, ebp 
pop ebp 
ret 0 
_main ENDP 
_code$ = 8 ; size = 4 
_ep$ = 12 ; size = 4 
filter user exceptions PROC 
push ebp 
mov ebp, esp 
mov eax, DWORD PTR  code$[ebp] 
push eax 


push OFFSET $SG85486 ; ‘in filter. code=0x%08X' 
call printf 
add esp, 8 
cmp DWORD PTR code$[ebp], 1122867 ; 00112233H 
jne SHORT $LN2@filter use 
push OFFSET $SG85488 ; 'yes, that is our exception' 
call printf 
add esp, 4 
mov eax, 1 
jmp SHORT $LN3@filter_use 
jmp SHORT $LN3@filter_use 
$LN2Gfilter use: 
push OFFSET $SG85490 ; ‘not our exception' 
call printf 
add esp, 4 


xor eax, eax 
$LN3@filter use: 
pop ebp 
ret 0 


filter user exceptions ENDP 


La signification de cookies est la suivante: Cookie Offset est la différence entre 
l'adresse dans la pile dela derniére valeur sauvegardée du registre EBP et de l'adresse 
dans la pile du résultat de l'addition EBP e security cookie. Cookie XOR Offset est 
quant à lui la différence entre EBP e security cookie et la valeur conservée sur la pile. 


Si le prédicat ci-dessous n'est pas respecté, le processus est arrété du fait d'une 
corruption de la pile: 


security cookie ® (Cookie X ORO f f set + address of saved EBP) == 
stack|address of saved EBP + CookieOf f set] 


Lorsque Cookie Offset vaut -2, ceci indique qu'il n'est pas présent. 


Windows x64 


Vous imaginez bien qu'il n'est pas trés performant de construire le contexte SEH 
dans le prologue de chaque fonction. S'y ajoute les nombreux changements de la 
valeur de previous try level durant l'exécution de la fonction. 
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C'est pourquoi avec x64, la maniére de faire a complétement changé. Tous les poin- 
teurs vers les blocs try, les filtres et les gestionnaires sont désormais stockés dans 
une nouveau segment PE: .pdata à partir duquel les gestionnaires d'exception de 
l'OS récupéreront les informations. 


Voici deux exemples tirés de la section précédente et compilés pour x64: 


Listing 6.33 : MSVC 2012 


$5G86276 DB ‘hello #1!', OaH, 00H 
$SG86277 DB ‘hello #2!', OaH, 00H 
$SG86279 DB ‘access violation, can''t recover', OaH, 00H 


pdata SEGMENT 
$pdata$main DD imagerel $LN9 


DD imagerel $LN9+61 
DD imagerel $unwind$main 
pdata ENDS 


pdata SEGMENT 
$pdata$main$filt$0 DD imagerel main$filt$0 


DD imagerel main$filt$0+32 
DD imagerel $unwind$main$filt$0 
pdata ENDS 


xdata SEGMENT 
$unwind$main DD 020609H 


DD 030023206H 
DD imagerel _ C specific handler 
DD 01H 
DD imagerel $LN9+8 
DD imagerel $LN9+40 
DD imagerel main$filt$0 
DD imagerel $LN9+40 
$unwind$main$filt$O DD 020601H 
DD 050023206H 
xdata ENDS 
TEXT | SEGMENT 
main PROC 
$LN9: 
push rbx 
sub rsp, 32 
xor ebx, ebx 
lea rcx, OFFSET FLAT:$SG86276 ; ‘hello #1!' 
call printf 
mov DWORD PTR [rbx], 13 
lea rcx, OFFSET FLAT:$SG86277 ; ‘hello #2!' 
call printf 
jmp SHORT $LN8@main 
$LN6@main: 
lea rcx, OFFSET FLAT:$SG86279 ; ‘access violation, can''t 
recover' 


call printf 

npad 1 ; align next label 
$LN8@main: 

xor eax, eax 
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add rsp, 32 
pop rbx 
ret 0 

main ENDP 

TEXT ENDS 


text$x SEGMENT 
main$filt$0 PROC 


push rbp 

sub rsp, 32 

mov rbp, rdx 
$LN5@main$filt$: 

mov rax, QWORD PTR [rcx] 

xor ecx, ecx 

cmp DWORD PTR [rax], -1073741819; c0000005H 

sete cl 

mov eax, ecx 
$LN7Gmain$filt$: 

add rsp, 32 

pop rbp 

ret 0 

int 3 


main$filt$0 ENDP 
text$x ENDS 


Listing 6.34 : MSVC 2012 


$SG86277 DB ‘in filter. code=0x%08X', 0aH, 00H 

$5G86279 DB ‘yes, that is our exception', OaH, OOH 
$5G86281 DB ‘not our exception', OaH, OOH 

$SG86288 DB 'hello!', OaH, 00H 

$SG86290 DB '0x112233 raised. now let''s crash', 0aH, OOH 
$SG86292 DB ‘access violation, can''t recover', OaH, OOH 
$5G86294 DB ‘user exception caught', 0aH, OOH 


pdata SEGMENT 
$pdata$filter user exceptions DD imagerel $LN6 


DD imagerel $LN6+73 

DD imagerel $unwind$filter user exceptions 
$pdata$main DD  imagerel $LN14 

DD imagerel $LN14+95 

DD imagerel $unwind$main 
pdata ENDS 


pdata SEGMENT 
$pdata$main$filt$0 DD imagerel main$filt$0 


DD imagerel main$filt$0+32 

DD imagerel $unwind$main$filt$0 
$pdata$main$filt$1 DD imagerel main$filt$1 

DD imagerel main$filt$1+30 

DD imagerel $unwind$main$filt$1 
pdata ENDS 


xdata | SEGMENT 
$unwind$filter user exceptions DD 020601H 
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'hello!' 


'0x112233 raised. now let''s 


'access violation, can''t 


'user exception caught' 


DD 030023206H 
$unwind$main DD 020609H 
DD 030023206H 
DD imagerel | C specific handler 
DD 02H 
DD imagerel $LN14+8 
DD imagerel $LN14+59 
DD imagerel main$filt$0 
DD imagerel $LN14+59 
DD imagerel $LN14+8 
DD imagerel $LN14+74 
DD imagerel main$filt$1 
DD imagerel $LN14+74 
$unwind$main$filt$O DD 020601H 
DD 050023206H 
$unwind$main$filt$1 DD 020601H 
DD 050023206H 
xdata ENDS 
TEXT | SEGMENT 
main PROC 
$LN14: 
push rbx 
sub rsp, 32 
xor ebx, ebx 
lea rcx, OFFSET FLAT:$SG86288 ; 
call printf 
xor r9d, r9d 
xor r8d, r8d 
xor edx, edx 
mov ecx, 1122867 ; 00112233H 
call QWORD PTR imp RaiseException 
lea rcx, OFFSET FLAT:$SG86290 ; 
crash' 
call printf 
mov DWORD PTR [rbx], 13 
jmp SHORT $LN13@main 
$LN11@main: 
lea rcx, OFFSET FLAT:$SG86292 ; 
recover! 
ca printf 
npad 1 ; align next label 
$LN13Gmain: 
jmp SHORT $LN9@main 
$LN7@main: 
lea rcx, OFFSET FLAT:$SG86294 ; 
call printf 
npad 1 ; align next label 
$LN9@main: 
xor eax, eax 
add rsp, 32 
pop rbx 
ret 0 
main ENDP 
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text$x SEGMENT 
main$filt$0 PROC 

push rbp 

sub rsp, 32 

mov rbp, rdx 
$LN10@main$filt$: 

mov rax, QWORD PTR [rcx] 

xor ecx, ecx 

cmp DWORD PTR [rax], -1073741819; 

sete cl 

mov eax, ecx 
$LN12@main$filt$: 

add rsp, 32 

pop rbp 

ret 0 

int 3 


main$filt$0 ENDP 


main$filt$1 PROC 


push rbp 
sub rsp, 32 
mov rbp, rdx 
$LN6Q@main$filt$: 
mov rax, QWORD PTR [rcx] 
mov rdx, rcx 
mov ecx, DWORD PTR [rax] 
call filter_user_exceptions 
npad 1 ; align next label 
$LN8Emain$filts$: 
add rsp, 32 
pop rbp 
ret 0 
int 3 
main$filt$1 ENDP 
text$x ENDS 
TEXT | SEGMENT 
code$ - 48 
ep$ - 56 
filter user exceptions PROC 
$LN6: 
push rbx 
sub rsp, 32 
mov ebx, ecx 
mov edx, ecx 
lea rcx, OFFSET FLAT:$SG86277 ; 
call printf 
cmp ebx, 1122867; 00112233H 
jne SHORT $LN2@filter_use 
lea rcx, OFFSET FLAT:$SG86279 ; 
call printf 
mov eax, 1 


c0000005H 


‘in filter. code=0x%08X' 


'yes, that is our exception' 
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add rsp, 32 

pop rbx 

ret 0 
$LN2Gfilter use: 

lea rcx, OFFSET FLAT:$SG86281 ; 'not our exception' 

call printf 

xor eax, eax 

add rsp, 32 

pop rbx 

ret 0 
filter user exceptions ENDP 
TEXT ENDS 


Pour plus d'informations sur le sujet, lisez [Igor Skochinsky, Compiler Internals: Ex- 
ceptions and RTTI, (2012)] °°. 


Hormis les informations d'exception, .pdata est aussi une section qui contient les 
adresses de début et de fin de toutes les fonctions. Elle revét donc un intérét parti- 
culier dans le cadre d'une analyse automatique d'un programme. 


En lire plus sur SEH 


[Matt Pietrek, A Crash Course on the Depths of Win32™ Structured Exception Hand- 
ling, (1997)P?!, [Igor Skochinsky, Compiler Internals: Exceptions and RTTI, (2012)] 
52 


6.5.4 Windows NT: Section critique 


Dans tout OS, les sections critiques sont trés importantes dans un systéme multi- 
threadé, principalement pour donner la garantie qu'un seul thread peut accéder à 
certaines données à un instant précis, en bloquant les autres threads et les interrup- 
tions. 


Voilà comment une structure CRITICAL SECTION est déclarée dans la série des OS 
Windows NT : 


Listing 6.35 : (Windows Research Kernel v1.2) public/sdk/inc/nturtl.h 


typedef struct RTL CRITICAL SECTION { 
PRTL CRITICAL SECTION DEBUG DebugInfo; 


// 

// The following three fields control entering and exiting the critical 
// section for the resource 

// 


LONG LockCount; 


50 Aussi disponible en http: //yurichev.com/mirrors/RE/Recon-2012- Skochinsky-Compiler-Internals. 
pdf 

51Aussi disponible en http: //www.microsoft.com/msj/0197/Exception/Exception.aspx 

52Aussi disponible en http: //yurichev.com/mirrors/RE/Recon- 2012-Skochinsky-Compiler-Internals. 
pdf 
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LONG RecursionCount; 


HANDLE OwningThread; // from the thread's ClientId->UniqueThread 
HANDLE LockSemaphore; 
ULONG PTR SpinCount; // force size on 64-bit systems when packed 


) RTL CRITICAL SECTION, *PRTL CRITICAL SECTION; 


Voilà comment la fonction EnterCriticalSection() fonctionne: 


Listing 6.36 : Windows 2008/ntdll.dll/x86 (begin) 


_RtlEnterCriticalSection@4 


var_C = dword ptr -OCh 
var 8 - dword ptr -8 
var 4 - dword ptr -4 
arg 0 - dword ptr 8 
mov edi, edi 
push ebp 
mov ebp, esp 
sub esp, OCh 
push esi 
push edi 
mov edi, [ebp+arg 0] 
lea esi, [edi+4] ; LockCount 
mov eax, esi 
lock btr dword ptr [eax], 0 
jnb wait ; jump if CF=0 
loc 7DE922DD: 
mov eax, large fs:18h 
mov ecx, [eax+24h] 
mov [edi+0Ch], ecx 
mov dword ptr [edi+8], 1 
pop edi 
xor eax, eax 
pop esi 
mov esp, ebp 
pop ebp 
retn 4 


. skipped 


L'instruction la plus importante dans ce morceau de code est BTR (préfixée avec 
LOCK) : 


Le bit d'index zéro est stocké dans le flag CF et est effacé en mémoire. Ceci est une 
opération atomique, bloquant tous les autres accés du CPU à cette zone de mémoire 
(regardez le préfixe LOCK se trouvant avant l'instruction BTR). Si le bit en LockCount 
est 1, bien, remise à zéro et retour de la fonction: nous sommes dans une section 
critique. 


Si non—la section critique est déjà occupée par un autre thread, donc attendre. L'at- 
tente est effectuée en utilisant WaitForSingleObject(). 
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Et voici comment la fonction LeaveCriticalSection() fonctionne: 


Listing 6.37 : Windows 2008/ntdll.dll/x86 (begin) 


_RtlLeaveCriticalSection@4 proc near 


arg_0 = dword ptr 8 
mov edi, edi 
push ebp 
mov ebp, esp 
push esi 
mov esi, [ebp+arg_0] 
add dword ptr [esi+8], OFFFFFFFFh ; RecursionCount 
jnz short loc 7DE922B2 
push ebx 
push edi 
lea edi, [esi+4] ; LockCount 
mov dword ptr [esi+0Ch], 0 
mov ebx, 1 
mov eax, edi 
lock xadd [eax], ebx 
inc ebx 
cmp ebx, OFFFFFFFFh 
jnz loc 7DEA8EB7 
loc 7DE922B0: 
pop edi 
pop ebx 
loc 7DE922B2: 
xor eax, eax 
pop esi 
pop ebp 
retn 4 


. skipped 


XADD signifie «exchange and add » (échanger et ajouter). 


Dans ce cas, elle ajoute 1 à LockCount, en méme temps qu'elle sauve la valeur 
initiale de LockCount dans le registre EBX. Toutefois, la valeur dans EBX est incré- 
mentée avec l'aide du INC EBX subséquent, et il sera ainsi égal à la valeur modifiée 
de LockCount. 


Cette opération est atomique puisqu'elle est préfixée par LOCK, signifiant que tous 
les autres CPUs ou coeurs de CPU dans le systéme ne peuvent pas accéder à cette 
zone de la mémoire. 


Le préfixe LOCK est trés important: 


sans lui deux threads, travaillant chacune sur un CPU ou un coeur de CPU séparé 
pourraient essayer d'entrer dans la section critique et de modifier la valeur en mé- 
moire, ce qui résulterait en un comportement non déterministe. 


Chapitre 7 


Outils 


Maintenant que Dennis Yurichev a réalisé ce 
livre gratuit, il s'agit d'une contribution au 
monde de la connaissance et de l'éducation 
gratuite. Cependant, pour l'amour de la 
liberté, nous avons besoin d'outils de 
rétro-ingénierie (libres) afin de remplacer les 
outils propriétaires mentionnés dans ce livre. 


Richard M. Stallman 


7.1 Analyse statique 


Outils à utiliser lorsqu'aucun processus n'est en cours d'exécution. 


(Gratuit, open-source) ent! : outil d'analyse d'entropie. En savoir plus sur l'en- 
tropie : 9.2 on page 1225. 


Hiew? : pour de petites modifications de code dans les fichiers binaires. Inclut 
un assembleur/désassembleur. 


Libre, open-source GHex? : éditeur hexadécimal simple pour Linux. 
(Libre, open-source) xxd et od : utilitaires standards UNIX pour réaliser un dump. 


(Libre, open-source) strings : outil *NIX pour rechercher des chaines ASCII dans 
des fichiers binaires, fichiers exécutables inclus. Sysinternals ont une alterna- 
tive ^ qui supporte les larges chaines de caractéres (UTF-16, trés utilisé dans 
Windows). 


(Libre, open-source) Binwalk? : analyser les images firmware. 


lhttp://www.fourmilab.ch/random/ 

2hiew.ru 

3https://wiki.gnome.org/Apps/Ghex 
4https://technet.microsoft.com/en-us/sysinternals/strings 
5http://binwalk.org/ 
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(Libre, open-source) binary grep : un petit utilitaire pour rechercher une sé- 
quence d'octets dans un paquet de fichiers, incluant ceux non exécutables : 
GitHub. Il y a aussi rafind2 dans rada.re pour le méme usage. 


7.1.1 Désassembleurs 


IDA. Une ancienne version Freeware est disponible via téléchargement 9. Anti- 
séche des touches de raccourci: .6.1 on page 1354 


(Gratuit, open-source) Ghidra’ — une alternative libre et open-source de IDA 
développée par la NSA?. 


Binary Ninja? 
(Gratuit, open-source) zynamics BinNavi'? 


(Gratuit, open-source) objdump : simple utilitaire en ligne de commandes pour 
désassembler et réaliser des dumps. 


(Gratuit, open-source) readelf!! : réaliser des dumps d'informations sur des 
fichiers ELF. 


7.1.2 Décompilateurs 


I| n'existe qu'un seul décompilateur connu en C, d'excellente qualité et disponible 
au public Hex-Rays : 
hex-rays.com/products/decompiler/ 


Pour en savoir plus: 11.9 on page 1301. 


Il y a une alternative libre développée par la NSA : Ghidra 


12 


7.1.3 Comparaison de versions 


Vous pouvez éventuellement les utiliser lorsque vous comparez la version originale 
d'un exécutable et une version remaniée, pour déterminer ce qui a été corrigé et en 
déterminer la raison. 


(Gratuit) zynamics BinDiff?? 


(Gratuit, open-source) Diaphora'^ 


Shex-rays.com/products/ida/support/download_Freeware.shtml 
7https://ghidra-sre.org/ 

8National Security Agency (Agence Nationale de la Sécurité) 
9http://binary.ninja/ 
IOhttps://www.zynamics.com/binnavi.html 
lMhttps://sourceware.org/binutils/docs/binutils/readelf.html 
12https://ghidra-sre.org/ 
13https://www.zynamics.com/software.html 
Mhttps://github.com/joxeankoret/diaphora 
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7.2 Analyse dynamique 


Outils à utiliser lorsque que le systéme est en cours d'exploitation ou lorsqu'un pro- 
cessus est en cours d'exécution. 


7.2.1 Débogueurs 


* (Gratuit) OllyDbg. Débogueur Win32 trés populaire ^. Anti-séche des touches 
de raccourci: .6.2 on page 1355 


(Gratuit, open-source) GDB. Débogueur peu populaire parmi les ingénieurs en 
rétro-ingénierie, car il est principalement destiné aux programmeurs. Quelques 
commandes : .6.5 on page 1356. Il y a une interface graphique pour GDB, “GDB 
dashboard”?*. 


(Gratuit, open-source) LLDB?". 


WinDbg?? : débogueur pour le noyau Windows. 


(Gratuit, open-source) Radare AKA rada.re AKA r2??. Une interface graphique 
existe aussi : ragui?°. 


(Gratuit, open-source) tracer. L'auteur utilise souvent tracer ?! au lieu d'un dé- 
bogueur. 


L'auteur de ces lignes a finalement arrété d'utiliser un débogueur, depuis que 
tout ce dont il a besoin est de repérer les arguments d'une fonction lorsque 
cette derniére est exécutée, ou l'état des registres à un instant donné. Le temps 
de chargement d'un débogueur étant trop long, un petit utilitaire sous le nom 
de tracer a été conçu. Il fonctionne depuis la ligne de commandes, permettant 
d'intercepter l'exécution d'une fonction, en placant des breakpoints à des en- 
droits définis, en lisant et en changeant l'état des registres, etc... 


N.B.: tracer n'évolue pas, parce qu'il a été développé en tant qu'outil de dé- 
monstration pour ce livre, et non pas comme un outil dont on se servirait au 
quotidien. 


7.2.2 Tracer les appels de librairies 


Itrace??. 


lSollydbg.de 

l6https://github.com/cyrus-and/gdb-dashboard 

Vhttp://lldb.llvm.org/ 
l8https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit 
19http://rada.re/r/ 

20http://radare.org/ragui/ 

?lyurichev.com 

22http://www.ltrace.org/ 
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7.2.3 Tracer les appels systéme 
strace / dtruss 


Montre les appels systéme (syscalls(6.3 on page 972)) effectués dans l'immédiat. 


Par exemple: 


# strace df -h 


access("/etc/ld.so.nohwcap", F OK) = -1 ENOENT (No such file or 7 
\ directory) 

open("/lib/i386-linux-gnu/libc.so.6", O RDONLY|O CLOEXEC) = 3 

read(3, "M177ELF2 


S \1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\232\1\0004\0\0\0"..., 2 
& 512) = 512 
fstat64(3, (st mode=S IFREG|0755, st size-1770984, ...}) = 0 


mmap2(NULL, 1780508, PROT READ|PROT EXEC, MAP PRIVATE]MAP DENYWRITE, 3, 0) 7 
& = 0xb75b3000 


Mac OS X a dtruss pour faire la méme chose. 


Cygwin a également strace, mais de ce que je sais, cela ne fonctionne que pour les 
fichiers .exe compilés pour l'environnement Cygwin lui-méme. 


7.2.4 Sniffer le réseau 


Sniffer signifie intercepter des informations qui peuvent vous intéresser. 


(Gratuit, open-source) Wireshark?? pour sniffer le réseau. Peut également sniffer les 
protocoles USB ?^. 


Wireshark a un petit (ou vieux) frère tcpdump??, outil simple en ligne de commandes. 


7.2.5 Sysinternals 


(Gratuit) Sysinternals (développé par Mark Russinovich) 2°. Ces outils sont impor- 
tants et valent la peine d'étre étudiés : Process Explorer, Handle, VMMap, TCPView, 
Process Monitor. 


7.2.6 Valgrind 


(Gratuit, open-source) un puissant outil pour détecter les fuites mémoire : http: 
//valgrind.org/. Gráce à ses puissants mécanismes JIT ("Just In Time"), Valgrind 
est utilisé comme un framework pour d'autres outils. 


23https://www.wireshark.org/ 

2^ https://wiki.wireshark.org/CaptureSetup/USB 
25http://www.tcpdump.org/ 
26https://technet.microsoft.com/en-us/sysinternals/bb842062 
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7.2.7 Emulateurs 


e (Gratuit, open-source) QEMU?” : émulateur pour différents CPUs et architec- 
tures. 


e (Gratuit, open-source) DosBox?? : émulateur MS-DOS, principalement utilisé 
pour le rétro-gaming. 


* (Gratuit, open-source) SimH?? : émulateur d'anciens ordinateurs, unités cen- 
trales, etc... 


7.3 Autres outils 


Microsoft Visual Studio Express ?? : Version gratuite simplifiée de Visual Studio, pra- 
tique pour des études de cas simples. 


Quelques options utiles : .6.3 on page 1355. 


Il y a un site web appelé “Compiler Explorer", permettant de compiler des petits 
morceaux de code et de voir le résultat avec des versions variées de GCC et d'archi- 
tectures (au moins x86, ARM, MIPS) : http://godbolt.org/—Je l'aurais utilisé pour 
le livre si je l'avais connu! 


7.3.1 Solveurs SMT 


Du point de vue de rétro-ingénieur, les solveurs SAT sont utilisés lorsque l'on fait 
face à de la cryptogrphie amateur, de l'exécution symoblique/concolique, de la gé- 
nération de chaine ROP. 


Pour plus d'information, lire: https://yurichev.com/writings/SAT SMT by example. 
pdf. 


7.3.2 Calculatrices 


Une bonne calculatrice pour les besoins des rétro-ingénieurs doit au moins supporter 
les bases décimale, hexadécimale et binaire, ainsi que plusieurs opérations impor- 
tantes comme XOR et les décalages. 


* IDA possède une calculatrice intégrée ("?"). 
* rada.re a rax2. 
* https://yurichev.com/progcalc/ 


* En dernier recours, la calculatrice standard de Windows dispose d'un mode 
programmeur. 


27http://qemu.org 

28https://www.dosbox.com/ 
?9http://simh.trailing-edge.com/ 

39 visualstudio.com/en-US/products/visual-studio-express-vs 
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7.4 Un outil manquant? 


Si vous connaissez un bon outil non listé précédemment, n'hésitez pas à m'en faire 
la remarque : 


my emails. 


Chapitre 8 


Études de cas 


Plutót qu'un épigraphe: 


Peter Seibel: Comment vous attaquez-vous à la lecture de code 
source? Méme lire quelque chose dans un langage de programmation 
que vous connaissez déjà est un probléme délicat. 

Donald Knuth: Mais ca vaut vraiment la peine pour ce que ca 
construit dans votre cerveau. Donc, comment est-ce que je fais? Il y 
avait une machine appelée le Bunker Ramo 300 et quelqu'un m'avait 
dit que le compilateur ForTran pour cette machine était incroyablement 
rapide, mais personne n'avait la moindre idée de pourquoi il fonction- 
nait. Je me suis procuré une copie du listing de son code source. Je 
n'avais pas de manuel pour la machine, donc je n'étais méme pas súr 
de ce qu'était son langage machine. 

Mais j'ai pris ca comme un défi intéressant. J'ai pu découvrir BEGIN 
et j'ai alors commencé à décoder. Les codes opération avaient des 
sortes de mnémoniques sur deux lettres et donc j'ai pu commencer 
à comprendre que "Ceci était probablement une instruction de char- 
gement, ceci probablement un branchement". Et je savais qu'il s'agis- 
sait d'un compilateur ForTran, donc à un moment donné j'ai regardé 
la colonne sept d'une carte, et c'était où ça disait s'il s'agissait d'un 
commentaire ou non. 

Aprés trois heures, j'en avais découvert un peu à propos de cette 
machine. Alors, j'ai trouvé cette grosse table de branchement. Donc, 
c'était un puzzle et j'ai continué à faire des petits graphiques comme si 
jetravaillais dans un un organisme de sécurité essayant de décoderun 
code secret. Mais je savais que ca fonctionnait et je savais que c'était 
un compilateur ForTran-ce n'était pas chiffré dans le sens où ca serait 
volontairement opaque; c'était seulement du code car je n'avais pas 
recu le manuel de cette machine. 

Enfin j'ai réussi à comprendre pourquoi ce compilateur était si ra- 
pide. Malheureusement ce n'était pas parce que son algorithme était 
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brillant; c'était seulement parce qu'ils avaient utilisé une programma- 
tion non structurée et optimisé le code manuellement. 

C'était simplement la facon de résoudre une énigme inconnue-faire 
des tableaux et des graphiques et y obtenir un peu plus d'informations 
et faire une hypothése. En général lorsque je lis un papier technique, 
c'est le méme défi. J'essaye de me mettre dans l'esprit de l'auteur, 
pour essayer de comprendre ce qu'est le concept. Plus vous apprenez 
à lire les trucs des autres, plus vous serez capable d'inventer les votre 
dans le futur, il me semble. 


( Peter Seibel — Coders at Work: Reflections on the Craft of Programming )* 


8.1 Blague avec le solitaire Mahjong (Windows 7) 


Le solitaire Mahjong est un bon jeu, mais pouvons-nous le rendre plus difficile, en 
désactivant l'élément de menu Hint? 


Dans mon Windows 7, je peux trouver Mahjong.dll et Mahjong.exe dans: 

C:\Windows\winsxs\ 

x86 microsoft-windows-s..inboxgames-shanghai 31bf3856ad364e35 6.1.7600.16385 none\ 
c07a51d9507d9398. 


Aussi le fichier Mahjong.exe.mui dans: 

C: NWindowsNwinsxsN 

x86 microsoft-windows-s..-shanghai.resources 31bf3856ad364e35 6.1.7600.16385 en-us 
_c430954533c66bf3 


et 


C:\Windows\winsxs\ 
x86 microsoft-windows-s..-shanghai.resources 31bf3856ad364e35 6.1.7600.16385 ru-ru 
. 0d51acf984cb679a. 


J'utilise Windows en anglais, mais avec le support du langage russe, donc il peut y 
avoir des fichiers de ressource pour ces deux langages. En ouvrant Mahjong.exe.mui 
dans Resource Hacker, nous pouvons y voir une définition de menu: 


Listing 8.1 : Ressource de menu de Mahjong.exe.mui 


103 MENU 
LANGUAGE LANG ENGLISH, SUBLANG ENGLISH US 


POPUP "&Game" 

1 
MENUITEM "&New GameNtF2", 40000 
MENUITEM SEPARATOR 
MENUITEM "&Undo\tCtrl+Z", 40001 
MENUITEM "&HintNtH", 40002 
MENUITEM SEPARATOR 


INDT: ouvrage non traduit en francais, la traduction, et les fautes, sont miennes. 
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MENUITEM "&StatisticsNtF4", 40003 
MENUITEM "&Options\tF5", 40004 

MENUITEM "Change &AppearanceNtF7", 40005 
MENUITEM SEPARATOR 

MENUITEM "E&xit", 40006 


} 

POPUP "&Help" 

{ 
MENUITEM "&View Help1tF1", 40015 
MENUITEM "&About Mahjong Titans", 40016 
MENUITEM SEPARATOR 
MENUITEM "Get &More Games Online", 40020 


Le sous-menu Hint a le code 40002. Maintenant, j'ouvre Mahjong.exe dans IDA et 
trouve la valeur 40002. 


(J'écris ceci en novembre 2019. Il semble qu’IDA ne puisse pas obtenir les PDBs 
depuis les serveurs de Microsoft. Peut-étre que Windows 7 n'est plus supporté? En 
tout cas, je ne peux pas obtenir les noms de fonction...) 


Listing 8.2 : Mahjong.exe 


.text:010205C8 6A 03 push 3 
.text:010205CA 85 FF test edi, edi 
.text:010205CC 5B pop ebx 
.text:01020625 57 push edi ; UIDEnableltem 
.text:01020626 FF 35 C8 97 08 01 push hmenu ; hMenu 
.text:0102062C FF D6 call esi ; EnableMenuItem 
.text:0102062E 83 7D 08 01 cmp [ebp+arg_0], 1 
.text:01020632 BF 42 9C 00 00 mov edi, 40002 
.text:01020637 75 18 jnz short loc 1020651 ; must jump 
always 
.text:01020639 6A 00 push 0 ; uEnable 
.text:0102063B 57 push edi ; UIDEnableltem 
.text:0102063C FF 35 B4 8B 08 01 push hMenu ; hMenu 
.text:01020642 FF D6 call esi ; EnableMenuItem 
.text:01020644 6A 00 push 0 ; uEnable 
.text:01020646 57 push edi ; uIDEnableItem 
.text:01020647 FF 35 C8 97 08 01 push hmenu ; hMenu 
.text:0102064D FF D6 call esi ; EnableMenuItem 
.text:0102064F EB 1A jmp short loc 102066B 
.text:01020651 
.text:01020651 loc 1020651: ; CODE XREF: sub 1020581+B6 
.text:01020651 53 push ebx TES 
.text:01020652 57 push edi ; UIDEnableltem 
.text:01020653 FF 35 B4 8B 08 01 push hMenu ; hMenu 
.text:01020659 FF D6 call esi ; EnableMenuItem 
.text:0102065B 53 push ebx 23 
.text:0102065C 57 push edi ; uIDEnableItem 
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.text:0102065D FF 35 C8 97 08 01 push hmenu ; hMenu 
.text:01020663 FF D6 call esi ; EnableMenuItem 


Ce morceau de code active ou désactive l'élément de menu Hint. 
Et d'aprés MSDN? : 
MF DISABLED | MF GRAYED = 3 et MF ENABLED = 0. 


Je pense que cette fonction active ou désactive plusieurs élément de menu (Hint, 
Undo, etc), suivant la valeur dans arg 0. Car au début, lorsqu'un utilisateur choisi 
le type de solitaire Hint et Undo sont désactivés. Ils sont activés lorsque le jeu a 
commencé. 


Je modifie le fichier Mahjong.exe en 0x01020637, en remplacant l'octet 0x75 avec 
OxEB, rendant ce saut JNZ toujours pris. Pratiquement, ceci va toujours appeler 
EnableMenuItem(..., ..., 3). Maintenant le sous-menu Hint est toujours désac- 
tivé. 

Aussi, de maniére ou d'une autre, EnableMenuItem() est appelé deux fois, pour 
hMenu et pour hmenu. Peut-étre que le programme a deux menus, et peut-étre les 
échange-t-il? 


À titre d'exercice, essayez de désactiver l'élément de menu Undo, pour rendre le jeu 
encore plus difficile. 


8.2 Blague avec le gestionnaire de táche (Windows 
Vista) 


Voyons s'il est possible de légérement modifier le gestionnaire de táches pour qu'il 
détecte plus de coeurs CPU. 


Demandons-nous d'abord, comment est-ce que le gestionnaire de táches connait le 
nombre de coeurs? 


Il y a une fonction win32 GetSystemInfo() présente dans l'espace utilisateur win32 
qui peut nous dire ceci. Mais elle n'est pas importées dans taskmgr.exe. 


Il y en a, toutefois, une autre dans NTAPI, NtQuerySystemInformation(), qui est 
utilisée dans taskmgr.exe à plusieurs endroits. 


Pour obtenir le nombre de coeurs, il faut appeler cette fonction avec la constante 
SystemBasicInformation comme premier argument (qui vaut zéro?). 


Le second argument doit pointer vers le buffer qui va recevoir toute l'information. 


Donc nous devons trouver tous les appels à la fonction 
NtQuerySystemInformation(0, ?, ?, ?). Ouvrons taskmgr.exe dans IDA. 


Ce qui est toujours bien avec les exécutables Microsoft, c'est que IDA peut téléchar- 
ger le fichier PDB correspondant à cet exécutable et afficher les noms de toutes les 
fonctions. 


?https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enablemenuitem 
3MSDN 
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Il est visible que le gestionnaire des táches est écrit en C++ et certains noms de 
fonction et classes sont vraiment parlants. ll y a des classes CAdapter, CNetPage, 
CPerfPage, CProcinfo, CProcPage, CSvcPage, CTaskPage, CUserPage. 


Il semble que chaque onglet du gestionnaire de tâches ait une classe correspon- 
dante. 


Regardons chaque appel et ajoutons un commentaire avec la valeur qui est passée 
comme premier argument de la fonction. Nous allons écrire «not zero» à certains 
endroits, car la valeur n'est clairement pas zéro, mais quelque chose de vraiment 
différent (plus à ce propos dans la seconde partie de ce chapitre). 


Et nous cherchons les zéros passés comme argument aprés tout. 


xrefsto — imp NtQuerySystemInformation 


win ain+50E cs:__imp_NtQuerySystemlnformation; O 
m Up wink ain+542 cal cs; imp_NtQuerySysteminformation; 2 


CPerfPage:: T imerE vent(void]« 200 . imp NtQuerySystemlnformation; not zero 
Lal p InitPerflnfo[(void]«2C cal cs; imp NtQuerySystemlnformation; O 
LD. p InitPerflnfo(void)«FÜ cal cs; imp NtQuerySystemlnformation; 8 
LD. p  CalcCpuTimelint)+5F cal cs; imp NtQuerySystemlnformation; 8 
LD. p  CalcCpuTimelint)+248 cal cs; imp NtQuerySystemlnformation; 2 
ib... p  CPerfPage::CalcPhysicalMem[unsigned... call cs; imp _NtQuerySysteminformation; not zero 
LLD... p CPerfPage:CalcPhysicaldMem[unsigned … call cs; imp NtQuerySystemlnformation; not zero 
LLD... p  CProcPage:GetProcesslnfo[void)«2B cal cs; imp NtQuerySystemlnformation; 5 
LLD... p  CProcPage:lUpdateProclnfo&rray[void]e.. call cs; imp _NtQuerySysteminformation; 0 
LLD... p  CProcPage:lUpdateProclnfo&rray(void]e... call cs; imp NtQuerySystemlnformation; 2 
LD... p  CProcPage:lnitialize(Hw/ND — *)+201 cal cs; imp NtQuerySystemlnformation; O 
LD. p  CProcPage::GetT askListE x[void}+3C cal cs; imp NtQuerySystemlnformation; 5 


Fig. 8.1: IDA: références croisées vers NtQuerySystemlnformation() 


Oui, les noms parlent vraiment d'eux-méme. 


Nous allons examiner précisément les endroits oü 
NtQuerySystemInformation(0, ?, ?, ?) estappelée, nous trouvons rapidement 
ce que nous cherchons dans la fonction InitPerfInfo(): 


Listing 8.3 : taskmgr.exe (Windows Vista) 


. text: 10000B4B3 xor r9d, r9d 

. text: 10000B4B6 lea rdx, [rsp+0C78h+var_C58] ; buffer 

. text: 10000B4BB xor ecx, ecx 

. text: 10000B4BD lea ebp, [r9+40h] 

. text: 10000B4C1 mov r8d, ebp 

. text: 10000B4C4 call cs: imp NtQuerySystemInformation ; 0 
.text:10000BACA xor ebx, ebx 

. text: 10000B4CC cmp eax, ebx 


.text:10000BACE jge short loc 10000B4D7 
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. text: 10000B4D0 

. text: 10000B4D0 loc 10000B4D0: ; CODE XREF: 
InitPerfinfo(void)+97 

. text: 10000B4D0 ; 
InitPerfinfo(void)+AF 

. text: 10000B4D0 xor al, al 

. text: 10000B4D2 jmp loc_10000B5EA 

.text:10000B4D7 ; 


.text:10000B4D7 


.text:10000B4D7 loc_10000B4D7: ; CODE XREF: 
InitPerfInfo(void)+36 

. text: 10000B4D7 mov eax, [rsp+0C78h+var_C50] 

. text: 10000B4DB mov esi, ebx 

. text: 10000B4DD mov rl2d, 3E80h 

. text: 10000B4E3 mov cs:?g PageSize@@3KA, eax ; ulong g PageSize 

. text: 10000B4E9 shr eax, OAh 

. text: 10000B4EC lea r13, __ImageBase 

. text: 10000B4F3 imul eax, [rsp+0C78h+var_C4C] 

. text: 10000B4F8 cmp [rsp+0C78h+var C20], bpl 

. text: 10000B4FD mov cs:?g MEMMax@@3 JA, rax ; int64 g MEMMax 

. text: 10000B504 movzx eax, [rsp+0C78h+var_C20] ; number of CPUs 

.text:10000B509 cmova eax, ebp 

.text:10000B50C cmp al, bl 

.text:10000B50E mov cs:?g cProcessors@@3EA, al ; 


uchar g cProcessors 


g cProcessors est une variable globale, et ce nom a été assigné par IDA suivant le 
symbole PDB chargé depuis le serveur de Microsoft. 


L'octet est pris de var C20. Et var C58 est passée à 
NtQuerySystemInformation() comme un pointeur sur le buffer de réception. La 
différence entre 0xC20 et 0xC58 est 0x38 (56). 


Regardons le format de la structure renvoyée, que nous pouvons trouver dans MSDN: 


typedef struct SYSTEM BASIC INFORMATION { 
BYTE Reserved1[24]; 
PVOID Reserved2[4]; 
CCHAR NumberOfProcessors; 

) SYSTEM BASIC INFORMATION; 


Ceci est un systéme x64, donc chaque PVOID occupe 8 octets. 
Tous les champs réservés dans la structure occupent 24 + 4 « 8 — 56 octets. 


Oh oui, ceci implique que var C20 dans la pile locale est exactement le champ 
NumberOfProcessors de la structure SYSTEM BASIC INFORMATION. 


Vérifions notre hypothèse. Copier taskmgr.exe depuis C:\Windows\System32 dans 
un autre répertoire (ainsi le Windows Resource Protection ne va pas essayer de res- 
taurer l'ancienne version du taskmgr.exe modifié). 


Ouvrons-le dans Hiew et trouvons l'endroit: 
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Fig. 8.2: Hiew: trouver l'endroit à modifier 


Remplacons l'instruction MOVZX par la notre. Prétendons avoir un CPU 64 cœurs. 


Ajouter un NOP additionnel (car notre instruction est plus courte que l'originale) : 


Fig. 8.3: Hiew: modification effectuée 


Et ca fonctionne! Bien sûr, les données dans les graphes ne sont pas correctes. 


À certains moments, le gestionnaire de táches montre méme une charge globale du 
CPU de plus de 100%. 


¡E Windows Task Manager 
File Options View Help 


Applications | Processes | Services | Performance | Networking | Users 


CPU Usage CPU Usage History 


Memory Physical Memory Usage History 


Fig. 8.4: Gestionnaire de táches Windows fou 


Le plus grand nombre avec lequel le gestionnaire de táches ne plante pas est 64. 


Il semble que le gestionnaire de táche de Windows Vista n'a pas été testé sur des 
ordinateurs avec un grand nombre de coeurs. 


Il doit y avoir une sorte de structure de données dedans. limitée à 64 coeurs (ou 
plusieurs). 


8.2.1 Utilisation de LEA pour charger des valeurs 


Parfois, LEA est utilisée dans taskmgr.exe au lieu de MOV pour définir le premier 
argument de 
NtQuerySystemInformation() : 


Listing 8.4 : taskmgr.exe (Windows Vista) 


xor r9d, rod 

div dword ptr [rsp+4C8h+WndClass.lpfnwWndProc] 
lea rdx, [rsp+4C8h+VersionInformation] 

lea ecx, [r9+2] ; put 2 to ECX 

mov r8d, 138h 


mov ebx, eax 
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; ECX=SystemPerformanceInformation 


call cs: imp NtQuerySystemInformation ; 2 
mov r8d, 30h 
lea r9, [rsp+298h+var_268] 
lea rdx, [rsp+298h+var_258] 
lea ecx, [r8-2Dh] ; put 3 to ECX 
; ECXsSystemTimeOfDayInformation 
call cs: imp NtQuerySystemInformation ; not zero 
mov rbp, [rsi+8] 
mov r8d, 20h 
lea r9, [rsp+98h+arg_0] 
lea rdx, [rsp+98h+var_78] 
lea ecx, [r8+2Fh] ; put Ox4F to ECX 
mov [rsp+98h+var 60], ebx 
mov [rsp+98h+var 68], rbp 
; ECX=SystemSuperfetchInformation 
call cs: imp NtQuerySystemInformation ; not zero 


Peut-étre que MSVC fit ainsi car le code machine de LEA est plus court que celui de 
MOV REG, 5 (il serait de 5 au lieu de 4). 


LEA avec un offset dans l'intervalle -128..127 (l'offset occupe 1 octet dans l'opcode) 
avec des registres 32-bit est encore plus court (faute de préfixe REX )—3 octets. 


Un autre exemple d'une telle chose: 6.1.5 on page 959. 
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8.3 Blague avec le jeu Color Lines 


Ceci est un jeu trés répandu dont il existe plusieurs implémentations. Nous utili- 
sons l'une d'entre elles, appelée BallTriX, de 1997, disponible librement ici https: 
//archive.org/details/BallTriX 1020 ^. Voici à quoi il ressemble: 


Total cells: 


Cells left: 


Row: 


Fig. 8.5: Ceci est l'allure du jeu en général 


4Ou ici  https://web.archive.org/web/20141110053442/http: //www.download- central .ws/ 
Win32/Games/B/BallTriX/ ou http://www. benya.com/balltrix/. 
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Dons regardons s'il est possible de trouver le générateur d'aléas et de jouer des tours 
avec. IDA reconnaît rapidement la fonction standard rand dans balltrix.exe en 
0x00403DA0. IDA montre aussi qu'elle n'est appelée que d'un seul endroit: 


.text:00402C9C sub 402C9C proc near ; 
CODE XREF: sub 402ACA+52 

.text:00402C9C ; sub 402ACA+64 ... 

.text:00402C9C 

.text:00402C9C arg 0 = dword ptr 8 

.text:00402C9C 

.text:00402C9C push ebp 

.text:00402C9D mov ebp, esp 

.text:00402C9F push ebx 

. text: 00402CA0 push esi 

. text: 00402CA1 push edi 

. text: 00402CA2 mov eax, dword 40D430 

. text: 00402CA7 imul eax, dword 40D440 

. text: 00402CAE add eax, dword_40D5C8 

. text: 00402CB4 mov ecx, 32000 

. text: 00402CB9 cdq 

. text: 00402CBA idiv ecx 

.text:00402CBC mov dword 40D440, edx 

.text:00402CC2 call rand 

.text:00402CC7 cdq 

.text:00402CC8 idiv [ebp+arg_ 0] 

.text:00402CCB mov dword 40D430, edx 

.text:00402CD1 mov eax, dword 40D430 

.text:00402CD6 jmp $45 

.text:00402CDB pop edi 

.text:00402CDC pop esi 

.text:00402CDD pop ebx 

.text:00402CDE leave 

.text:00402CDF retn 

.text:00402CDF sub 402C9C endp 


Appelons-la «random ». Ne plongeons pas encore dans le code de cette fonction. 
Cette fonction est référencée depuis 3 endroits. 


Voici les deux premiers: 


.text:00402B16 mov eax, dword 40C03C ; 10 here 
.text:00402B1B push eax 

.text:00402B1C call random 

.text:00402B21 add esp, 4 

.text:00402B24 inc eax 

.text:00402B25 mov [ebp+var C], eax 
.text:00402B28 mov eax, dword 40C040 ; 10 here 
.text:00402B2D push eax 

.text :00402B2E call random 

.text:00402B33 add esp, 4 


Voici le troisième: 
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. text :00402BBB 
.text:00402BC0 
.text:00402BC1 
.text:00402BC6 
.text:00402BC9 


mov 
push 
call 
add 
inc 


eax, dword 40C058 ; 5 here 
eax 

random 

esp, 4 

eax 


Donc la fonction n'a qu'un argument. 


10 est passé dans les deux premiers cas et 5 dans le troisiéme. Nous pouvons aussi 
remarquer que le plateau a une taille de 10*10, et qu'il y a 5 couleurs possible. C'est 
ca! La fonction standard rand() renvoie un nombre dans l'intervalle 0. .Ox7FFF et 
c'est souvent peu pratique, donc beaucoup de programmeurs implémentent leur 
propre fonction qui renvoie un nombre aléatoire dans un intervalle spécifié. Dans 
notre cas, l'intervalle est 0... - 1 et n est passé comme unique argument à la fonction. 
Nous pouvons tester cela rapidement dans le débogueur. 


Donc modifions le troisiéme appel de la fonction, afin qu'il renvoie toujours zéro. Pre- 
miérement, nous allons remplacer trois instructions (PUSH/CALL/ADD) par des NOPs. 
Puis, nous allons ajouter l'instruction XOR EAX, EAX pour effacer le registre EAX. 


.00402BB8: 
.00402BBB: 
.00402BC0: 
.00402BC2: 
.00402BC3: 
.00402BC4: 
.00402BC5: 
.00402BC6: 
.00402BC7: 
.00402BC8: 
.00402BC9: 
.00402BCA: 
.00402BCD: 
.00402BD0: 


83C410 
A158C04000 
31C0 


8D0C49 
8B15F4D54000 


add 
mov 
xor 
nop 
nop 
nop 
nop 
nop 
nop 
nop 
inc 
mov 
lea 
mov 


esp,010 
eax, [00040C058] 
eax,eax 


eax 
ecx, [ebp][-8] 
ecx, [ecx] [ecx]*2 
edx, [00040D5F4] 


Nous avons remplacé l'appel à la fonction random() par du code qui renvoie toujours 


zéro. 


1047 


Lancons-le maintenant: 


FF]Ballrrix TES] 
File Help 


Score: fi 


7 O 
(2 E EE EE ERG ENT 
[TT eee 
Cells left: 89 
eee nee 


Fig. 8.6: La blague fonctionne 


Hé oui, ca fonctionne?. 


Mais pourquoi est-ce que les arguments de la fonction random() sont des variables 
globales? C'est seulement parce qu'il est possible de changer la taille du plateau 
dans les préférences du jeu, donc ces valeurs ne sont pas codées en dur. Le valeurs 
10 et 5 sont celles par défaut. 


8.4 Démineur (Windows XP) 


Pour ceux qui ne sont pas trés bons avec le jeu démineur, nous pouvons essayer de 
révéler les mines cachées dans le débogueur. 


Comme on le sait, le démineur place des mines aléatoirement, donc il doit y avoir 
une sorte de générateur de nombre aléatoire ou un appel à la fonction C standard 
rand(). 


Ce qui est vraiment cool en rétro-ingénierant des produits Microsoft c'est qu'il y a 
les fichiers PDB avec les symboles (nom de fonctions, etc.) Lorsque nous chargeons 
winmine.exe dans IDA, il télécharge le fichier PDB exact pour cet exécutable et 
affiche tous les noms. 


Donc le voici, le seul appel à rand() est cette fonction: 


.text:01003940 ;  stdcall Rnd(x) 
.text:01003940 Rnd@4 proc near ; CODE XREF: 
StartGame()+53 


5)’ai fait une fois cette blague à des collègues dans l'espoir qu'ils arrêtent de jouer. Mais ca n'a pas 
fonctionné. 
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.text:01003940 ; StartGame()+61 
.text:01003940 

.text:01003940 arg 0 = dword ptr 4 

.text:01003940 

.text:01003940 call ds: imp rand 

.text:01003946 cdq 

.text:01003947 idiv [esp+arg_0] 

.text:0100394B mov eax, edx 

.text:0100394D retn 4 

.text:0100394D Rnd@4 endp 


IDA l'a appelé ainsi, et c'est le nom que lui ont donné les développeurs du démineur. 


La fonction est trés simple: 


int Rnd(int limit) 
1 


return rand() % limit; 


(Il n'y a pas de nom «limit» dans le fichier PDB; nous avons nommé manuellement 
les arguments comme ceci.) 


Donc elle renvoie une valeur aléatoire entre 0 et la limite spécifiée. 


Rnd() est appelée depuis un seul endroit, la fonction appelée StartGame(), et il 
semble bien que ce soit exactement le code qui place les mines: 


.text:010036C7 push _xBoxMac 

.text:010036CD call _Rnd@4 ; Rnd(x) 

. text: 010036D2 push _yBoxMac 

.text:010036D8 mov esi, eax 

.text:010036DA inc esi 

.text:010036DB call _Rnd@4 ; Rnd(x) 

. text: 010036E0 inc eax 

.text:010036E1 mov ecx, eax 

.text:010036E3 shl ecx, 5 ; ECX=ECX*32 
. text: 010036E6 test _rgBlk[ecx+esil, 80h 

. text: 010036EE jnz short loc 10036C7 
.text:010036F0 shl eax, 5 ; EAX=EAX*32 
. text: 010036F3 lea eax, _rgBlk[eax+esi] 

. text: 010036FA or byte ptr [eax], 80h 

. text: 010036FD dec _cBombStart 

.text:01003703 jnz short loc 10036C7 


Le démineur vous permet de définir la taille du plateau, donc les dimensions X (xBox- 
Mac) et Y (yBoxMac) du plateau sont des variables globales. Elles sont passées à 
Rnd() et des coordonnées aléatoires sont générées. Une mine est placée par l'ins- 
truction OR en 0x010036FA. Et si une mine y a déjà été placée avant (il est possible 
que la fonction Rnd( ) génére une paire de coordonnées qui a déjà été générée), alors 
les instructions TEST et JNZ en 0x010036E6 bouclent sur la routine de génération. 


cBombStart est la variable globale contenant le nombre total de mines. Donc ceci 
est une boucle. 
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La largeur du tableau est 32 (nous pouvons conclure ceci en regardant l'instruction 
SHL, qui multiplie l'une des coordonnées par 32). 


La taille du tableau global rgBlk peut facilement être déduite par la différence entre 
le label rgBlk dans le segment de données et le label suivant. Il s'agit de 0x360 
(864) : 


.data:01005340 _rgBlk db 360h dup(?) ; DATA XREF: 
MainWndProc(x,x,x,x)+574 

.data:01005340 ; DisplayBlk(x,x)+23 

.data:010056A0 Preferences dd ? ; DATA XREF: 


FixMenus ()+2 


864/32 = 27. 


Donc, la taille du tableau est-elle 27«32? C'est proche de ce que nous savons: lorsque 
nous essayons de définir la taille du plateau à 100 + 100 dans les préférences du 
démineur, il corrige à une taille de plateau de 24* 30. Donc ceci est la taille maximale 
du plateau. Et le tableau a une taille fixe, pour toutes les tailles de plateau. 


REgardons tout ceci dans OllyDbg. Nous allons lancer le démineur, lui attacher Ol- 
lyDbg et nous allons pouvoir voir le contenu de la mémoire à l'adresse du tableau 
rgBlk (0x01005340)5. Donc nous avons ceci à l'emplacement mémoire du tableau: 


Address | Hex dump 

01005340 10 10 10 10|10 10 10 10|10 10 10 OF|OF OF OF OF| 
01005350 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005360 10 OF OF OF|OF OF OF OF|OF OF 10 OF|OF OF OF OF| 
01005370 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005380 10 OF OF OF|OF OF OF OF|OF OF 10 OF|OF OF OF OF| 
01005390 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010053A0 10 OF OF OF|OF OF OF OF|8F OF 10 OF|OF OF OF OF| 
010053B0 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010053C0 10 OF OF OF|OF OF OF OF|OF OF 10 OF|OF OF OF OF] 
010053D0 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010053E0 10 OF OF OF|OF OF OF OF|OF OF 10 OF|OF OF OF OF] 
010053F0 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005400 10 OF OF 8F|OF OF 8F OF|OF OF 10 OF|OF OF OF OF] 
01005410 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005420 10 8F OF OF|8F OF OF OF|OF OF 10 OF|OF OF OF OF| 
01005430 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005440 10 8F OF OF|OF OF 8F OF|OF 8F 10 OF|OF OF OF OF] 
01005450 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005460 10 OF OF OF|OF 8F OF OF|OF 8F 10 OF|OF OF OF OF] 
01005470 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
01005480 10 10 10 10/10 10 10 10|10 10 10 OF|OF OF OF OF| 
01005490 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010054A0 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010054B0 OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 
010054CO OF OF OF OF|OF OF OF OF|OF OF OF OF|OF OF OF OF| 


SToutes les adresses ici sont pour le démineur de Windows XP SP3 English. Elles peuvent être différentes 
pour d’autres services packs. 
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OllyDbg, comme tout autre éditeur hexadécimal, affiche 16 octets par ligne. Donc 
chaque ligne de tableau de 32-octet occupe exactement 2 lignes ici. 


Ceci est le niveau débutant (plateau de 9*9). 
Il y a une sorte de structure carré que l'on voit ici (octets 0x10). 


Nous cliquons «Run » dans OllyDbg pour débloquer le processus du démineur, puis 
nous cliquons au hasard dans la fenétre du démineur et nous tombons sur une mine, 
mais maintenant, toutes les mines sont visibles: 


* Minesweeper Ps [el JE | 


Game Help 


|| © - 


Fig. 8.7: Mines 


En comparant les emplacements des mines et le dump, nous pouvons en conclure 
que 0x10 correspond au bord, OxOF—bloc vide, Ox8F—mine. Peut-étre que 0x10 est 
simplement une valeur sentinelle. 


Maintenant nous allons ajouter des commentaires et aussi mettre tous les octets à 
Ox8F entre parenthéses droites: 


border: 
01005340 10 10 10 10 10 10 10 10 10 10 10 OF OF OF OF OF 
01005350 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #1: 
01005360 10 OF OF OF OF OF OF OF OF OF 10 OF OF OF OF OF 
01005370 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #2: 
01005380 10 OF OF OF OF OF OF OF OF OF 10 OF OF OF OF OF 
01005390 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #3: 
010053A0 10 OF OF OF OF OF OF OF[8F]OF 10 OF OF OF OF OF 
010053B0 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #4: 
010053C0 10 OF OF OF OF OF OF OF OF OF 10 OF OF OF OF OF 
010053D0 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #5: 


1051 


010053E0 10 OF OF OF OF OF OF OF OF OF 10 OF OF OF OF OF 
010053F0 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #6: 

01005400 10 OF OF[8F]OF OF[8F]OF OF OF 10 OF OF OF OF OF 
01005410 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #7: 

01005420 10[8F]0F OF[8F]OF OF OF OF OF 10 OF OF OF OF OF 
01005430 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #8: 

01005440 10[8F]OF OF OF OF[8F]OF OF[8F]10 OF OF OF OF OF 
01005450 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
line #9: 

01005460 10 OF OF OF OF[8F]OF OF OF[8F]10 OF OF OF OF OF 
01005470 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 
border: 

01005480 10 10 10 10 10 10 10 10 10 10 10 OF OF OF OF OF 
01005490 OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF OF 


Maintenant nous allons supprimer tous les octet de bord (0x10) et ce qu'il y a aprés: 


OF OF OF OF OF OF OF OF OF 
OF OF OF OF OF OF OF OF OF 
OF OF OF OF OF OF OF[8F]OF 
OF OF OF OF OF OF OF OF OF 
OF OF OF OF OF OF OF OF OF 
OF OF[8F]0F OF[8F]OF OF OF 
[8F]OF OF[8F]OF OF OF OF OF 
[8F]OF OF OF OF[8F]OF OF[8F] 
OF OF OF OF[8F]OF OF OF[8F] 


Oui, ce sont des mines, maintenant ca peut étre vu clairement et comparé avec la 
copie d'écran. 
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Ce qui est intéressant, c'est que nous pouvons modifier le tableau directement dans 


OllyDbg. Nous pouvons supprimer toutes les mines en changeant les octets à Ox8F 
par OxOF, et voici ce que nous obtenons dans le démineur: 


Game Help 


Fig. 8.8: Toutes les mines sont supprimées depuis le débogueur 


Nous pouvons aussi toutes les déplacer à la première ligne: 


Game Help 


Fig. 8.9: Mines mises dans le débogueur 


Bon, le débogueur n'est pas trés pratique pour espionner (ce qui est notre but), donc 
nous allons écrire un petit utilitaire pour afficher le contenu du plateau: 
// Windows XP MineSweeper cheater 


// written by dennis(a)yurichev.com for http://beginners.re/ book 
#include «windows.h» 
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#include <assert.h> 
#include <stdio.h> 


int main (int argc, char * argv[]) 


{ 


int i, j; 

HANDLE h; 

DWORD PID, address, rd; 
BYTE board[27][32]; 


if (argc!=3) 

{ 
printf ("Usage: %s <PID> <address>\n", argv[0]); 
return 0; 


un 


assert (argv[1]!zNULL) ; 
assert (argv[2] !zNULL) ; 


assert (sscanf (argv[1], "*d", €PID)==1); 
assert (sscanf (argv[2], "%x", &address)--1); 


h=0penProcess (PROCESS VM OPERATION | PROCESS VM READ | 7 
& PROCESS VM WRITE, FALSE, PID); 


if (h==NULL) 
{ 


DWORD e=GetLastError(); 
printf ("OpenProcess error: %08X\n", e); 
return 0; 


un 


if (ReadProcessMemory (h, (LPVOID)address, board, sizeof(board), 


S rd) !=TRUE) 
1 
printf ("ReadProcessMemory() failed\n"); 
return 0; 


}; 


for (i=1; i<26; i++) 
1 
if (board[i][0]==0x10 && board[i] [1]==0x10) 
break; // end of board 
for (j=1; j<31; j++) 
{ 
if (board[i][j]==0x10) 
break; // board border 
if (board[i][j]==0x8F) 
printf ("*"); 
else 
printf (" "); 


8? 
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}; 


printf ("Xn"); 
}; 


CloseHandle (h); 


Simplement donner le PID” ê et l'adresse du tableau (0x01005340 pour Windows XP 
SP3 English) et il l'affichera °. 


Il s'attache à un processus win32 par le PID et lit la mémoire du processus à l'adresse. 


8.4.1 Trouver la grille automatiquement 


C'est pénible de mettre l'adresse à chaque fois que nous lançons notre utilitaire. 


Aussi, différentes versions du démineur peuvent avoir le tableau à des adresses 


différentes. Sachant qu'il a toujours un bord (octets 0x10), nous pouvons le trouver 
facilement en mémoire: 


// find frame to determine the address 
process mem-(BYTE*)malloc(process mem size); 
assert (process mem!-NULL); 


if (ReadProcessMemory (h, (LPVOID)start addr, process mem, 7 
S process mem size, &rd)!=TRUE) 
1 
printf ("ReadProcessMemory() failed\n"); 
return 0; 


}; 


// for 9*9 grid. 
// FIXME: slow! 
for (i=0; i<process mem size; i++) 


{ 
if (memcmp(process_mem+i, "\x10\x10\x10\x10\x10\x10\x10\x107 
& \XI10\XI10\X10\XOF\XOF\XOF\XOF\XOF\XOF\XOF\XOF\XOF\XOF\XOF\XxOF\XxOF\xOF\ 2 
& XOF\XOF\XOF\XOF\XOF\XxOF\xOF\x10", 32)==0) 


{ 
// found 
address=start_addr+i; 
break; 
}; 
}; 
if (address==0) 
{ 
printf ("Can't determine address of frame (and grid)\n"); 
return 0; 
} 
else 
{ 


71D d'un processus 
8Le PID peut être vu dans le Task Manager (l'activer avec «View — Select Columns ») 
9L'exécutable compilé est ici: beginners.re 
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printf ("Found frame and grid at Ox%x\n", address); 


}; 


Code source complet: https://beginners.re/paywall/RE4B-source/current-tree/ 
/examples/minesweeper/minesweeper cheater2.c. 


8.4.2 Exercices 


* Pourquoi est-ce que les octets de bord (ou valeurs sentinelles) (0x10) existent 
dans le tableau? 


À quoi servent-elles si elles ne sont pas visibles dans l'interface du démineur? 
Comment est-ce qu'il pourrait fonctionner sans elles? 


* Comme on s'en doute, il y a plus de valeurs possible (pour les blocs ouverts, 
ceux flagués par l'utilisateur, etc.). Essayez de trouver la signification de cha- 
cune d'elles. 


* Modifiez mon utilitaire afin qu'il puisse supprimer toutes les mines ou qu'il les 
place suivant un schéma fixé de votre choix dans le démineur. 


8.5 Hacker l'horloge de Windows 


Parfois je fais des poissons d'avril à mes collégues. 


Cherchons si nous pourrions faire quelque chose avec l'horloge de Windows? Pouvons- 
nous la forcer à tourner à l'envers? 


Tout d'abord, lorsque l'on clique sur date/time dans la barre d'état, 
le module C:\WINDOWS\SYSTEM32\TIMEDATE.CPL est exécuté, qui est un fichier exé- 
cutable PE habituel. 


Voyons d'abord comment il affiche les aiguilles. Lorsque j'ouvre le fichier (de Win- 
dows 7) dans Resource Hacker, il y a le fond de l'horloge, mais sans aiguille: 
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Resource Hacker - timedate.cpl - [nj x} 


File Edit View Action Help PNGFILE : 5000 : 1033 


Dogma. 


J) MUI 

wy 1: 1033 

jj PNGFILE 
w 
vy 5001: 1033 
wy 5002 : 1033 
vy 5003: 1033 
vy 5004 : 1033 
à 5005: 1033 
à 5006 : 1033 
vy 5007 : 1033 
vy 5008 : 1033 
wy 5009 : 1033 
vy 5010: 1033 
à 5011: 1033 


(Ml rur e 


24847| . | [130x130 PNG Ui 


Fig. 8.10: Resource Hacker 


Ok, que savons-nous? Comment afficher une aiguille? Elles commencent au milieu 
du cercle, s’arrétent sur son bord. De ce fait, nous devons calculer les coordon- 
nées d’un point sur le bord d’un cercle. Des mathématiques scolaires, nous pou- 
vons nous rappeler que nous devons utiliser les fonctions sinus/cosinus pour des- 
siner un cercle, ou au moins la racine carré. Il n'y a pas de telles choses dans TIl- 
MEDATE.CPL, au moins à premiére vue. Mais grace au fichier PDB de débogage de 
Microsoft, je peux trouver une fonction appelée CAnalogClock::DrawHand(), qui ap- 
pelle Gdiplus::Graphics::DrawLine() au moins deux fois. 


Voici le code: 


.text:6EB9DBC7 ; private: enum Gdiplus: :Status  thiscall 
CAnalogClock:: DrawHand(class Gdiplus::Graphics *, int, struct ClockHand 
const &, class Gdiplus::Pen *) 
.text:6EB9DBC7 ? DrawHand@CAnalogClock@@AAE? ? 
y AW4Status@Gdiplus@@PAVGraphics@3@HABUC LockHand@@PAVPen@3@@Z proc near 
.text:6EB9DBC7 ; CODE XREF: CAnalogClock:: ClockPaint(HDC__ *)+163 
. text: 6EB9DBC7 ; CAnalogClock:: ClockPaint(HDC__ *)+18B 
. text: 6EB9DBC7 
.text:6EB9DBC7 var 10 
.text:6EB9DBC7 var C 
.text:6EB9DBC7 var 8 
.text:6EB9DBC7 var 4 


dword ptr -10h 
dword ptr -0Ch 
dword ptr -8 
dword ptr -4 
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text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
S 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


6EB9DBC7 arg 0 
6EB9DBC7 arg 4 
6EB9DBC7 arg 8 
6EB9DBC7 arg C 
GEB9DBC7 
GEB9DBC7 
GEB9DBC9 
GEB9DBCA 
GEB9DBCC 
GEB9DBCF 
GEB9DBD2 
6EB9DBD3 
GEB9DBD4 
GEB9DBD5 
GEB9DBD6 
GEB9DBD8 
6EB9DBDA 
6EB9DBDB 
GEB9DBDD 
GEB9DBDF 
GEB9DBE6 
GEB9DBE9 
GEB9DBEA 
GEB9DBEC 
GEB9DBEF 
GEB9DBF2 
GEB9DBF9 
GEB9DBFC 


push 
mov 
sub 
mov 
push 
push 
push 
cdq 
push 
mov 
POP 
idiv 
push 
lea 
lea 
cdq 
idiv 
mov 
mov 
lea 
mov 
call 


ebp, esp 
esp, 10h 
eax, [ebp+arg 4] 


esi, ecx 
ecx 


ebx, table[edx*8] 
eax, [edx+1Eh] 


ecx 
ecx, [ebp+arg 0] 

[ebp+var 4], ebx 

eax, table[edx*8] 
[ebp+arg 4], eax 

22 


SetInterpolationMode@Graphics@Gdip Lus@@QAE? 7 
y AW4Status@2@W4InterpolationMode@2@@Z ; 
Gdiplus: :Graphics: :SetInterpolationMode(GdipLus: :InterpolationMode) 


GEB9DCO1 
6EB9DCO4 
6EB9DC07 
GEB9DCOA 
GEB9DCOD 
6EB9DC10 
6EB9DC12 
GEB9DC15 
GEB9DC1A 
6EB9DC1B 
6EB9DCIE 


MulDiv(x,x,x) 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


6EB9DC24 
GEB9DC26 
GEB9DC29 
GEB9DC2E 
6EB9DC31 
6EB9DC33 
6EB9DC36 
6EB9DC37 
6EB9DC3A 
GEB9DC3C 
GEB9DC3E 


mov 
mov 
mov 
mov 
mov 
mov 
sub 
push 
push 
push 
mov 


call 
add 
push 
mov 
mov 
sub 
push 
mov 
push 
call 
add 


eax, [esi+70h] 
edi, [ebp+arg 8] 
[ebp+var 10], eax 
eax, [esi+74h] 
[ebp+var_C], eax 


eax, [edi] 

eax, [edi+8] 

8000 ; nDenominator 
eax ; nNumerator 


dword ptr [ebx+4] ; nNumber 
ebx, ds: imp MulDivQ12 ; 


ebx ; MulDiv(x,x,x) ; MulDiv(x,x,x) 
eax, [esi+74h] 

8000 ; nDenominator 
[ebp+arg 8], eax 

eax, [edi] 

eax, [edi+8] 

eax ; nNumerator 

eax, [ebp+var_4] 

dword ptr [eax] ; nNumber 

ebx ; MulDiv(x,x,x) ; MulDiv(x,x,x) 
eax, [esi+70h] 
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. text: 6EB9DC41 mov ecx, [ebp+arg_0] 

. text: 6EB9DC44 mov [ebp+var_8], eax 

. text: 6EB9DC47 mov eax, [ebp+arg 8] 

. text: 6EB9DC4A mov [ebp+var_4], eax 

. text : 6EB9DC4D lea eax, [ebp+var 8] 

.text:6EB9DC50 push eax 

.text:6EB9DC51 lea eax, [ebp+var 10] 

.text:6EB9DC54 push eax 

.text:6EB9DC55 push [ebp«arg C] 

.text:6EB9DC58 call ?DrawLine@Graphics@Gdiplus@@QAE? 7 


& AW4Status@2@PBVPen@2@GABVPoint@2@1@Z ; 
Gdiplus::Graphics::DrawLine(Gdiplus::Pen const *,Gdiplus::Point const 
&,Gdiplus::Point const &) 


. text: 6EB9DC5D mov ecx, [edi+8] 

. text: 6EB9DC60 test ecx, ecx 

. text: 6EB9DC62 jbe short loc 6EB9DCAA 

. text: 6EB9DC64 test eax, eax 

. text: 6EB9DC66 jnz short loc 6EB9DCAA 

. text: 6EB9DC68 mov eax, [ebptarg 4] 

. text: 6EB9DC6B push 8000 ; nDenominator 

. text: 6EB9DC70 push ecx ; nNumerator 

. text: 6EB9DC71 push dword ptr [eax+4] ; nNumber 

. text: 6EB9DC74 call ebx ; MulDiv(x,x,x) ; MulDiv(x,x,x) 
.text:6EB9DC76 add eax, [esi+74h] 

. text: 6EB9DC79 push 8000 ; nDenominator 

. text: 6EB9DC7E push dword ptr [edi+8] ; nNumerator 
.text:6EB9DC81 mov [ebp+arg_8], eax 

.text:6EB9DC84 mov eax, [ebp+arg 4] 

. text: 6EB9DC87 push dword ptr [eax] ; nNumber 

. text: 6EB9DC89 call ebx ; MulDiv(x,x,x) ; MulDiv(x,x,x) 
. text: 6EB9DC8B add eax, [esi+70h] 

. text: 6EB9DC8E mov ecx, [ebp+arg 0] 

. text: 6EB9DC91 mov [ebp+var_8], eax 

. text: 6EB9DCI4 mov eax, [ebp+arg 8] 

. text: 6EB9DC97 mov [ebp+var_4], eax 

. text: 6EB9DCIA lea eax, [ebp+var 8] 

. text: 6EB9DC9D push eax 

.text:6EB9DC9E lea eax, [ebp+var 10] 

. text: 6EB9DCA1 push eax 

. text: 6EB9DCA2 push [ebp+arg_C] 

. text: 6EB9DCA5 call ?DrawLine@Graphics@Gdiplus@@QAE? 7 


& AW4Status@2@PBVPen@2@ABVPoint@2@1@Z ; 
Gdiplus: :Graphics: :DrawLine(Gdiplus::Pen const *,Gdiplus::Point const 
&,Gdiplus::Point const &) 

. text: 6EBODCAA 

. text: 6EB9DCAA loc_6EB9DCAA: ; CODE XREF: 


CAnalogClock:: DrawHand(Gdiplus::Graphics *,int,ClockHand const 
€, Gdiplus::Pen *)+9B 


. text: 6EB9DCAA ; CAnalogClock:: DrawHand(Gdiplus::Graphics 
*,int,ClockHand const &,Gdiplus::Pen *)+9F 

.text:6EB9DCAA pop edi 

. text: 6EB9DCAB pop esi 

. text: 6EB9DCAC pop ebx 

. text: 6EB9DCAD leave 


. text: 6EB9DCAE retn 10h 
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.text:6EB9DCAE ? DrawHand@CAnalogClock@@AAE? ^ 
y AW4Status@GdiplLus@@PAVGraphics@3@HABUC LockHand@@PAVPen@3@@Z endp 
. text: 6EB9DCAE 


Nous voyons que les arguments de DrawLine() dépendent du résultat de la fonction 
MulDiv() et d'une table table[] (le nom est mien), qui a des éléments de 8-octets 
(regardez le second opérande de LEA). 


Qu'y a-t-il dans table[]? 


.text:6EB87890 ; int table[] 


.text:6EB87890 table dd 0 
.text:6EB87894 dd OFFFFEOCIh 
.text:6EB87898 dd 344h 
.text:6EB8789C dd OFFFFEOECh 
.text:6EB878A0 dd 67Fh 
.text:6EB878A4 dd OFFFFE16Fh 
.text:6EB878A8 dd 9A8h 
.text:6EB878AC dd OFFFFE248h 
.text:6EB878B0 dd OCB5h 
.text:6EB878B4 dd OFFFFE374h 
.text:6EB878B8 dd OF9Fh 
.text:6EB878BC dd OFFFFE4FOh 
. text : 6EB878C0 dd 125Eh 

. text : 6EB878C4 dd OFFFFE6B8h 
.text:6EB878C8 dd 14E9h 


Elle n'est référencée que depuis la fonction DrawHand(). Elle a 120 mots de 32-bit ou 
60 paires 32-bit... attendez, 60? Regardons ces valeurs de plus prés. Tout d'abord, je 
vais remplacer 6 paires ou 12 mots de 32-bit par des zéros, et je vais mettre le fichier 
TIMEDATE.CPL modifié dans C:|WINDOWS|SYSTEM32. (Vous pourriez devoir changer 
le propriétaire du fichier *TIMEDATE.CPL* pour votre compte utilisateur primaire (au 
lieu de Trustedinstaller), et donc, démarrer en mode sans échec avec la ligne de 
commande afin de pouvoir copier le fichier, qui est en général bloqué.) 
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Monday, August 15, 2016 


Su Mo Tu We Th Fr Sa 
3 4 5 6 
10 11 12 13 
17 18 19 20 


24 25 26 27 \ / 
31 1 2 3 NU i 


2:01:02 PM 


Change date and time settings... 


, > 2:01PM 
ac 
Fig. 8.11: Tentative d'exécution 


Maintenant lorsqu'une aiguilles est située dans 0..5 secondes/minutes, elle est in- 
visible! Toutefois, la partie opposée (plus courte) de la seconde aiguille est visible 
et bouge. Lorsqu'une aiguille est en dehors de cette partie, elle est visible comme 
d'habitude. 


Regardons d' encore plus prés la table dans Mathematica. J'ai copié/collé la table 
de TIMEDATE.CPL dans un fichier tb! (480 octets). Nous tenons pour acquis le fait 
que ce sont des valeurs signées, car la moitié des éléments sont inférieurs à zéro 
(OFFFFEOCIh, etc.). Si ces valeurs étaient non signées, elles seraient étrangement 
grandes. 


In[]:= tbl = BinaryReadList["-/.../tbl", "Integer32"] 
Out[]= (0, -7999, 836, -7956, 1663, -7825, 2472, -7608, 3253, -7308, 3999, 7 


GN 
-6928, 4702, -6472, 5353, -5945, 5945, -5353, 6472, -4702, 6928, N 
-4000, 7308, -3253, 7608, -2472, 7825, -1663, 7956, -836, 8000, 0, \ 
7956, 836, 7825, 1663, 7608, 2472, 7308, 3253, 6928, 4000, 6472, N 
4702, 5945, 5353, 5353, 5945, 4702, 6472, 3999, 6928, 3253, 7308, N 
2472, 7608, 1663, 7825, 836, 7956, 0, 7999, -836, 7956, -1663, 7825, N 
-2472, 7608, -3253, 7308, -4000, 6928, -4702, 6472, -5353, 5945, N 
-5945, 5353, -6472, 4702, -6928, 3999, -7308, 3253, -7608, 2472, N 
-7825, 1663, -7956, 836, -7999, 0, -7956, -836, -7825, -1663, -7608, \ 
-2472, -7308, -3253, -6928, -4000, -6472, -4702, -5945, -5353, -5353, N 
-5945, -4702, -6472, -3999, -6928, -3253, -7308, -2472, -7608, -1663, N 
-7825, -836, -7956} 


In[]:= Length[tb1] 
= 120 


Traitons deux valeurs consécutives comme une paire: 


In[]:= pairs = Partition[tbl, 2] 
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Out[]= (10, -7999}, (836, -7956}, (11663, -7825), (2472, -7608}, \ 
(3253, -7308}, (3999, -6928}, (4702, -6472}, (5353, -5945}, (5945, \ 
-5353}, (6472, -4702}, (6928, -4000}, (7308, -3253}, (7608, -2472}, \ 
{7825, -1663}, {7956, -836}, {8000, 0}, {7956, 836}, {7825, 

1663}, {7608, 2472}, {7308, 3253}, {6928, 4000}, {6472, 

4702}, {5945, 5353}, {5353, 5945}, {4702, 6472}, {3999, 

6928}, {3253, 7308}, {2472, 7608}, {1663, 7825}, {836, 7956}, {0, 
7999}, {-836, 7956}, {-1663, 7825}, {-2472, 7608}, {-3253, 

7308}, {-4000, 6928}, {-4702, 6472}, {-5353, 5945}, {-5945, 

5353}, {-6472, 4702}, {-6928, 3999}, {-7308, 3253}, {-7608, 

2472}, {-7825, 1663}, {-7956, 836}, {-7999, 

O}, {-7956, -836}, {-7825, -1663}, {-7608, -2472}, {-7308, -3253}, \ 
{-6928, -4000}, {-6472, -4702}, {-5945, -5353}, {-5353, -5945}, \ 
{-4702, -6472}, {-3999, -6928}, {-3253, -7308}, {-2472, -7608}, \ 
{-1663, -7825}, {-836, -7956}} 


In[]: 
Out [] 


Length[pairs] 
60 


Essayons de traiter chaque paire comme des coordonnées X/Y et dessinons les 60 
paires, et aussi les 15 premiéres paires: 


1062 
Inf13J= ListPlot[pairs, AspectRatio > Full, ImageSize >» (300, 300}] 
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Inf27)= ListPlot[pairs[[1;; 15]], AspectRatio >» Full, ImageSize > (300, 300}] 
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Fig. 8.12: Mathematica 


Ca donne quelque chose! Chaque paire est juste une coordonnée. Les 15 premiéres 
paires sont les coordonnées pour ¿ de cercle. 


Peut-étre que les développeurs de Microsoft ont pré-calculé toutes les coordonnées 
et les ont mises dans une table. myindexMemoization Ceci est une pratique trés 
répandue, quoique désuéte - l'accés à une table précalculée est plus rapide que 
d'appeler les fonctions sinus/cosinus relativement lente!?. Les opérations sinus/co- 
sinus ne sont plus aussi couteuses... 


Maintenant, je comprends pourquoi lorsque j'ai effacé les 6 premiéres paires, les 


10Aujourd'hui ceci est appelé la memoisation 
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aiguilles étaient invisibles dans cette zone: en fait, les aiguilles étaient dessinées, 


elles avaient juste une longueur de zéro, car elles commencaient et finissaient en 
(0,0). 


La blague 


Sachant tout cela, comment serait-il possible de forcer les aiguilles à tourner à l'en- 
vers? En fait, ceci est simple, nous devons seulement tourner la table, afin que 
chaque aiguille, au lieu d'étre dessinée à l'index 0, le soit à l'index 59. 


J'ai créé le modificateur il y a longtemps, au tout début des années 2000, pour Win- 
dows 2000. Difficile à croire, il fonctionne toujours pour Windows 7, peut-étre que la 
table n'a pas changé depuis lors! 


Code source du modificateur: https: //beginners.re/paywall/RE4B-source/current-tree/ 
/examples/timedate/time pt.c. 


Maintenant, je peux voir les aiguilles tourner à l'envers: 


Saturday, August 13, 2016 


EN august,2016 D 
Su Mo Tu We Th Fr Sa 


12 3 4 5 6 
7 8 9 10 11 128 
14 15 16 17 18 19 20 


21 22 23 24 25 26 27 
zii b OAM 


28 29 30 31 1 2 


4 5 6 a g 


A+ 
9:32:09 AM 


Change date and time settings... 


Fig. 8.13: Maintenant ca fonctionne 


Bon, il n'y a pas d'animation dans ce livre, mais si vous y regardez de plus prés, 
vous pouvez voir que les aiguilles affichent en fait l'heure correcte, mais que la 
surface entiére de l'horloge est tournée verticalement, comme si nous la voyons 
depuis l'intérieur de l'horloge. 


Code source divulgué de Windows 2000 


Donc, j'ai écrit le modificateur et ensuite le code source de Windows 2000 a fuité 
(je ne peux toutefois pas vous obligez à me croire). Jettons un coup d'œil au code 
source de cette fonction et à la table. 

Le fichier est win2k/private/shell/cpls/utc/clock.c : 


1/7 


// Array containing the sine and cosine values for hand positions. 


// 
POINT rCircleTable[] = 
{ 

{ 0, -7999}, 

{ 836, -7956}, 

{ 1663, -7825}, 

{ 2472, -7608}, 

{ 3253, -7308}, 

{ -4702, -6472}, 

{ -3999, -6928}, 

{ -3253, -7308}, 

{ -2472, -7608}, 

{ -1663, -7825}, 

{ -836 , -7956}, 
}; 
LUI III TT TT I TA TT A A TA A A A A A A A A A A A A A A TA A A A A TT A TL LL LT LL LT TT TT 17 
// 
// DrawHand 
// 
// Draws the hands of the clock. 
// 


ARAS 


void DrawHand ( 
HDC hDC, 
int pos, 
HPEN hPen, 
int scale, 
int patMode, 
PCLOCKSTR np) 


LPPOINT lppt; 
int radius; 


MoveTo(hDC, np->clockCenter.x, np->clockCenter.y); 
radius = MulDiv(np->clockRadius, scale, 100); 

lppt = rCircleTable + pos; 

SetROP2(hDC, patMode) ; 

SelectObject(hDC, hPen); 


LineTo( hDC, 
np->clockCenter.x + MulDiv(lppt-»x, radius, 8000), 
np->clockCenter.y + MulDiv(lppt->y, radius, 8000) ); 


Maintenant, c'est clair: les coordonnées sont pré-calculées comme si la surface de 
l'horloge avait une hauteur et une largeur de 2-8000, et ensuite elles sont adaptées 
au rayon actuel de l'horloge en utilisant la fonction MulDiv(). 
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La structure POINT+} est une structure de deux valeurs 32-bit, la première est x, la 
seconde y. 


8.6 Solitaire (Windows 7) : blagues 


8.6.1 51 cartes 


Ceci est une blague que je fis une fois à mes collégues qui jouaient trop au jeu 
Solitaire. Je me demandais s'il était possible de supprimer quelques cartes, ou méme 
en ajouter (dupliquer). 


J'ai ouvert Solitaire.exe dans le dés-assembleur IDA, qui a demandé à télé-charger 
le fichier PDB depuis les serveurs de Microsoft. Ceci est habituellement la régle pour 
de nombreux exécutables et DLLs Windows. Au moins, le PDB contient tous les noms 
de fonctions. 


Ensuite j'ai essayé de trouver le nombre 52 dans toutes les fonctions (car ce jeu de 
carte utilise 52 cartes). Il s'est avéré que seulement 2 fonctions l'avait. 


La premiére est: 


.text:00000001000393B4 ; | int64  fastcall SolitaireGame: :OnMoveComplete( 7 
y SolitaireGame *this) 
.text:00000001000393B4 ?0nMoveComplete@SolitaireGame@@QEAAHXZ proc near 


La seconde est la fonction avec un nom significatif (nom tiré du PDB par IDA) : 
InitialDeal() : 


.text:00000001000365F8 ; void  fastcall SolitaireGame::InitialDeal(” 
y SolitaireGame * hidden this) 
.text:00000001000365F8 ?InitialDeal@SolitaireGame@@QEAAXXZ proc near 
.text:00000001000365F8 
.text:00000001000365F8 var_58 
.text:00000001000365F8 var_48 
.text:00000001000365F8 var_40 
.text:00000001000365F8 var_3C 
.text:00000001000365F8 var_38 
.text:00000001000365F8 var_30 
.text:00000001000365F8 var_28 
.text:00000001000365F8 var_18 
.text:00000001000365F8 
.text:00000001000365F8 ; FUNCTION CHUNK AT .text:00000001000A55C2 SIZE 7 
& 00000018 BYTES 
.text:00000001000365F8 


byte ptr -58h 
qword ptr -48h 
dword ptr -40h 
dword ptr -3Ch 
dword ptr -38h 
qword ptr -30h 
xmmword ptr -28h 
byte ptr -18h 


.text:00000001000365F8 ; | unwind { //  CxxFrameHandler3 
.text:00000001000365F8 mov rax, rsp 
.text:00000001000365FB push rdi 
.text:00000001000365FC push r12 
.text:00000001000365FE push r13 


Hhttps://msdn.microsoft.com/en-us/library/windows/desktop/dd162805(v2vs.85) .aspx 
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.text: 


y g pSolitaireGame@@3PEAVSolitaireGame@@EA 


G 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


rsp, 60h 
[rsp+78h+var_48], 07 


[rax+8], rbx 

[rax+10h], rbp 

[rax+18h], rsi 

xmmword ptr [rax-28h], xmm6 
rsi, rcx 
edx, edx ; struct 2 


?7 


SetSelectedCard@SolitaireGame@@QEAAXPEAVCard@@@Z ; SolitaireGame:: 7 


0000000100036600 sub 
0000000100036604 mov 
FFFFFFFFFFFFFFFEh 

000000010003660D mov 
0000000100036611 mov 
0000000100036615 mov 
0000000100036619 movaps 
000000010003661D mov 
0000000100036620 xor 
Card * 

0000000100036622 call 
SetSelectedCard(Card *) 
0000000100036627 and 
000000010003662F mov 


g pSolitaireGame 
0000000100036636 
000000010003663A 
000000010003663E 
0000000100036640 
0000000100036643 
0000000100036645 
0000000100036649 


PlaySoundProto@GameAudio@@YA NH NPEAIGZ ; 


int,bool,uint *) 
000000010003664E 
000000010003664E loc 10003664E: 


mov 
cmp 
jz 
xor 
mov 
lea 
call 


SolitaireGame::InitialDeal(void)+46 


000000010003664E mov 
0000000100036655 mov 
000000010003665B lea 
CardStack::CreateDeck()::uiNumSuits == 
0000000100036662 mov 
0000000100036667 mov 
int 

0000000100036669 call 
ushort const *,...) 

000000010003666E mov 
0000000100036674 lea 
CardStack::CreateDeck()::uiNumCards -- 
000000010003667B mov 
int 

000000010003667D call 
ushort const *,...) 

0000000100036682 xor 


0000000100036684 loc 100036684: 


SolitaireGame::InitialDeal(void)+C0 


0000000100036684 
0000000100036689 
000000010003668B 
000000010003668E 


mov 
mul 
mov 
shr 


qword ptr [rsi+0FOh], 0 
rax, cs:?2 
; SolitaireGame * 7 


rdx, [rax+48h] 
byte ptr [rdx+51h], 0 
short loc_10003664E 


r8d, r8d ; bool 
dl, 1 ; int 
ecx, [r8+3] ; this 
?2 


GameAudio::PlaySoundProto( 7 


; CODE XREF:Z 
rbx, [rsi+88h] 
r8d, 4 
rdx, aCardstackCreat ; "2 
ebp, 10000h 
ecx, ebp ; unsigned 7 


?LOg@@YAXIPEBGZZ ; Log(uint, ? 


r8d, 52 Po 
rdx, aCardstackCreat 0 ; "7 
ecx, ebp ; unsigned 2 


?LOg@@YAXIPEBGZZ ; Log(uint,/ 


edi, edi 
; CODE XREF:7 
eax, 4EC4EC4Fh 
edi 
r8d, edx 
red, 4 ; unsigned 7 
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& int 
.text:0000000100036692 mov eax, r8d 
.text:0000000100036695 imul eax, 52 poses 
. text :0000000100036698 mov edx, edi 
. text :000000010003669A sub edx, eax ; unsigned 7 
& int 
.text:000000010003669C mov rcx, [rbx+128h] ; this 
.text:00000001000366A3 call 27 
V CreateCard@CardTable@@IEAAPEAVCard@@II@Z ; CardTable::CreateCard(uint/ 
& ,uint) 
.text:00000001000366A8 mov rdx, rax ; struct 2 
& Card * 
.text:00000001000366AB mov rcx, rbx ; this 
.text:00000001000366AE call 27 
y Push@CardStack@@QEAAXPEAVCard@@@Z ; CardStack: :Push(Card *) 
.text:00000001000366B3 inc edi 
.text:00000001000366B5 cmp edi, 52 Ppo--- 
.text:00000001000366B8 jb short loc 100036684 
.text:00000001000366BA xor r8d, r8d ; bool 
.text:00000001000366BD xor edx, edx ; bool 
.text:00000001000366BF mov rcx, rbx ; this 
.text:00000001000366C2 call 27 
\ Arrange@CardStack@@QEAAX NOQZ ; CardStack::Arrange(bool,bool) 
.text:00000001000366C7 mov r13, [rsi+88h] 
.text:00000001000366CE lea rdx, aCardstackShuff ; "2 
y CardStack::Shuffle()" 
.text:00000001000366D5 mov ecx, ebp ; unsigned 7 
& int 
.text:00000001000366D7 call ?Log@@YAXIPEBGZZ ; Log(uint, 7 
& ushort const *,...) 
.text:00000001000366DC and [rsp+78h+var 40], 0 
. text :00000001000366E1 and [rsp+78h+var_3C], 0 
. text :00000001000366E6 mov [rsp+78h+var 38], 10h 
. text :00000001000366EE xor ebx, ebx 
. text :00000001000366F0 mov [rsp+78h+var_30], rbx 


De toutes facons, nous voyons clairement une boucle avec 52 itérations. Le corps de 
la boucle possède des appels a CardTable()::CreateCard() et CardStack: :Push(). 


La fonction CardTable::CreateCard() appelle finalement Card::Init() avec des 
valeurs dans l'intervalle 0..51, dans l'un de ses arguments. Ceci peut étre vérifié 
facilement dans un débogueur. 


Donc j'ai essayé de simplement changer le nombre 52 (0x34) en 51 (0x33) dans 
l'instruction cmp edi, 52 en 0x1000366B5 et de le lancer. A première vue, rien ne 
s'est passé, mais j'ai remarqué qu'il était maintenant difficile de résoudre le jeu. J'ai 
passé presque une heure pour atteindre cette position : 


B Solitaire 
Game Help 


Il manque l'as de cœur. Peut-être qu'en interne, cette carte a l'indice 51 (si les indices 
partent de zéro). 


Á un autre endroit, j'ai trouvé tous les noms des cartes. Peut-étre que les noms sont 
utilisés pour aller chercher l'image de la carte dans les ressources? 


.data:00000001000B6970 ?CARD NAME@Card@@2PAPEBGA dq offset aTwoofclubs 


.data:00000001000B6970 5 À 
& Two0fClubs" 

.data:00000001000B6978 dq offset aThreeofclubs ; "7 
S ThreeOfClubs" 

.data:00000001000B6980 dq offset aFourofclubs ; "7 
V FourOfClubs" 

.data:00000001000B6988 dq offset aFiveofclubs ; "7 
& FiveOfClubs" 

.data:00000001000B6990 dq offset aSixofclubs Eom 
S SixOfClubs" 

.data:00000001000B6998 dq offset aSevenofclubs ; "7 
& SevenOfClubs" 

.data:00000001000B69A0 dq offset aEightofclubs ; "7 
& EightOfClubs" 

.data:00000001000B69A8 dq offset aNineofclubs ; "7 
& NineOfClubs" 

.data:00000001000B69B0 dq offset aTenofclubs ; "2 


S TenOfClubs" 
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.data: 
- 
.data: 
GS 
.data: 
S 
.data: 
y 
.data: 
S 
.data: 
€ 
.data: 
- 
.data: 
ie 
.data: 
Ss 
.data: 
S 
.data: 
S 
.data: 
G 
.data: 
y 
.data: 
s. 
.data: 
S 
.data: 
S 
.data: 
S 
.data: 
G 
.data: 
" 
.data: 
y 
.data: 
Ss 
.data: 
y 
.data: 
S 
.data: 
G 
.data: 
S 
.data: 
G 
.data: 


00000001000B69B8 
JackOfClubs" 
00000001000B69C0 
Queen0fClubs" 
00000001000B69C8 
KingOfClubs" 
00000001000B69D0 
AceOfClubs" 
00000001000B69D8 
TwoOfDiamonds" 
00000001000B69E0 
ThreeOfDiamonds" 
00000001000B69E8 
FourOfDiamonds" 
00000001000B69F0 
FiveOfDiamonds" 
00000001000B69F8 
SixOfDiamonds" 
00000001000B6A00 
SevenOfDiamonds" 
00000001000B6A08 
EightOfDiamonds" 
00000001000B6A10 
NineOfDiamonds" 
00000001000B6A18 
TenOfDiamonds" 
00000001000B6A20 
JackOfDiamonds" 
00000001000B6A28 
QueenOfDiamonds" 
00000001000B6A30 
KingOfDiamonds" 
00000001000B6A38 
AceOfDiamonds" 
00000001000B6A40 
Two0fSpades" 
00000001000B6A48 
ThreeOfSpades" 
00000001000B6A50 
FourOfSpades" 
00000001000B6A58 
FiveOfSpades" 
00000001000B6A60 
SixOfSpades" 
00000001000B6A68 
SevenOfSpades" 
00000001000B6A70 
EightOfSpades" 
00000001000B6A78 
NineOfSpades" 
00000001000B6A80 
TenOfSpades" 
00000001000B6A88 


dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 


dq 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


aJackofclubs ; 
aQueenofclubs ; 
aKingofclubs ; 
aAceofclubs ; 
aTwoofdiamonds ; 
aThreeofdiamond 
aFourofdiamonds 
aFiveofdiamonds 
aSixofdiamonds ; 
aSevenofdiamond 
aEightofdiamond 
aNineofdiamonds 
aTenofdiamonds ; 


aJackofdiamonds 


aQueenofdiamond ; 


aKingofdiamonds ; 


aAceofdiamonds ; 
aTwoofspades ; 
aThreeofspades ; 
aFourofspades ; 
aFiveofspades ; 
aSixofspades ; 
aSevenofspades ; 
aEightofspades ; 
aNineofspades ; 
aTenofspades ; 


aJackofspades ; 


iid.) 
DEN. 


i A 


ap 


LS 


Be MD, 


pony 


"3 


12 
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bs 
.data: 
S 
.data: 
S 
.data: 
e 
.data: 
ee 
.data: 
i 
.data: 
S 
.data: 
y 
.data: 
&s 
.data: 
S. 
.data: 
" 
.data: 
S 
.data: 
& 
.data: 
S 
.data: 
G 
.data: 
E 
.data: 
is 


JackOfSpades" 
00000001000B6A90 
QueenOfSpades" 
00000001000B6A98 
KingOfSpades" 
00000001000B6AA0 
AceOfSpades" 
00000001000B6AA8 
TwoOfHearts" 
00000001000B6ABO 
ThreeOfHearts" 
00000001000B6AB8 
FourOfHearts" 
00000001000B6ACO 
FiveOfHearts" 
00000001000B6AC8 
SixOfHearts" 
00000001000B6ADO 
SevenOfHearts" 
00000001000B6AD8 
EightOfHearts" 
00000001000B6AE0 
NineOfHearts" 
00000001000B6AE8 
TenOfHearts" 
00000001000B6AF0 
JackOfHearts" 
00000001000B6AF8 
QueenOfHearts" 
00000001000B6B00 
KingOfHearts" 
00000001000B6B08 
AceOfHearts" 


dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 


dq 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


00000001000B6B10 ; public: static unsigned 


: :CARD HUMAN NAME 


aQueenofspades ; 
aKingofspades ; 
aAceofspades ; 
aTwoofhearts ; 
aThreeofhearts ; 
aFourofhearts ; 
aFiveofhearts ; 
aSixofhearts ; 
aSevenofhearts ; 
aEightofhearts ; 
aNineofhearts ; 
aTenofhearts ; 
aJackofhearts ; 
aQueenofhearts ; 
aKingofhearts ; 


aAceofhearts ; 


w 


"7 


short const * near * Card 


00000001000B6B10 ?CARD HUMAN NAME@Card@@2PAPEBGA dq offset 7 


a54639Cardnames 
00000001000B6B10 
CardNames|Two Of Clubs" 
00000001000B6B18 
CardNames|Three Of Clubs" 
00000001000B6B20 
CardNames|Four Of Clubs" 
00000001000B6B28 
CardNames|Five Of Clubs" 
00000001000B6B30 
CardNames|Six Of Clubs" 
00000001000B6B38 
CardNames|Seven Of Clubs" 
00000001000B6B40 
CardNames|Eight Of Clubs" 
00000001000B6B48 


dq 
dq 
dq 
dq 
dq 
dq 


dq 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


, 


a64833Cardnames 


a62984Cardnames 


a65200Cardnames 


a52967Cardnames 


a42781Cardnames 


a49217Cardnames 


a44682Cardnames 


"[54639| 7 

; "|64833|7 
; "|62984| 7 
; "|65200|» 
; "|52967 | 2 
: "|42781| 7 
; "|49217|7 


; "|44682| 7 
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CardNames|Nine Of Clubs" 


00000001000B6B50 
CardNames|Ten Of Clubs" 
00000001000B6B58 

CardNames |Jack 0f Clubs" 
00000001000B6B60 

CardNames |Queen Of Clubs" 
00000001000B6B68 
CardNames|King Of Clubs" 
00000001000B6B70 
CardNames|Ace Of Clubs" 
00000001000B6B78 
CardNames|Two Of Diamonds" 
00000001000B6B80 
CardNames|Three Of Diamonds" 
00000001000B6B88 
CardNames|Four Of Diamonds" 
00000001000B6B90 
CardNames|Five Of Diamonds" 
00000001000B6B98 
CardNames|Six Of Diamonds" 
00000001000B6BA0 
CardNames|Seven Of Diamonds" 
00000001000B6BA8 
CardNames|Eight Of Diamonds" 
00000001000B6BBO 
CardNames|Nine Of Diamonds" 
00000001000B6BB8 
CardNames|Ten Of Diamonds" 
00000001000B6BCO 

CardNames Jack Of Diamonds" 
00000001000B6BC8 

CardNames |Queen 0f Diamonds" 
00000001000B6BDO 
CardNames|King Of Diamonds" 
00000001000B6BD8 
CardNames|Ace Of Diamonds" 
00000001000B6BE0 
CardNames|Two Of Spades" 
00000001000B6BE8 
CardNames|Three Of Spades" 
00000001000B6BFO 
CardNames|Four Of Spades" 
00000001000B6BF8 
CardNames|Five Of Spades" 
00000001000B6C00 
CardNames|Six Of Spades" 
00000001000B6C08 

CardNames |Seven 0f Spades" 
00000001000B6C10 
CardNames|Eight Of Spades" 
00000001000B6C18 


CardNames|Nine Of Spades" 


dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 


dq 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


a51853Cardnames ; 


a46368Cardnames ; 


a61344Cardnames ; 


a65017Cardnames ; 


a57807Cardnames ; 


a48455Cardnames ; 


a44156Cardnames ; 


a51672Cardnames ; 


a45972Cardnames ; 


a47206Cardnames ; 


a48399Cardnames ; 


a47847Cardnames ; 


a48606Cardnames ; 


a61278Cardnames ; 


a52038Cardnames ; 


a54643Cardnames ; 


a48902Cardnames ; 


a46672Cardnames ; 


a41049Cardnames ; 


a49327Cardnames ; 


a51933Cardnames ; 


a42651Cardnames ; 


a65342Cardnames ; 


a53644Cardnames ; 


a54466Cardnames ; 


a56874Cardnames ; 


"151853 | 7 
"146368 | 2 
"161344 | > 
"165017 | 2 
"157807 | 2 
"148455 | 2 
"144156 | 2 
"151672 | 2 
"145972 | 2 
"147206 | 2 
"148399 | 2 
"147847 | 7 
"148606 | 2 
"161278 | 2 
"152038 | 2 
"154643 | > 
"148902 | 2 
"146672 | 2 
"141049 | > 
"149327 | 2 
"151933 | 2 
"|42651| 2 
"165342 | > 
"153644 | 2 
"154466 | 2 


"156874 | 7 
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00000001000B6C20 
CardNames|Ten Of Spades" 
00000001000B6C28 
CardNames|Jack 0f Spades" 
00000001000B6C30 

CardNames |Queen Of Spades" 
00000001000B6C38 
CardNames|King Of Spades" 
00000001000B6C40 
CardNames|Ace Of Spades" 
00000001000B6C48 
CardNames|Two Of Hearts" 
00000001000B6C50 
CardNames|Three Of Hearts" 
00000001000B6C58 

CardNames |Four 0f Hearts" 
00000001000B6C60 
CardNames|Five Of Hearts" 
00000001000B6C68 
CardNames|Six Of Hearts" 
00000001000B6C70 

CardNames |Seven 0f Hearts" 
00000001000B6C78 
CardNames|Eight Of Hearts" 
00000001000B6C80 
CardNames|Nine Of Hearts" 
00000001000B6C88 
CardNames|Ten Of Hearts" 
00000001000B6C90 
CardNames|Jack Of Hearts" 
00000001000B6C98 
CardNames|Queen Of Hearts" 
00000001000B6CAO 
CardNames|King Of Hearts" 
00000001000B6CA8 
CardNames|Ace Of Hearts" 


dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 
dq 


dq 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


offset 


a46756Cardnames ; 


a62876Cardnames ; 


a64633Cardnames ; 


a46215Cardnames ; 


a60450Cardnames ; 


a51010Cardnames ; 


a64948Cardnames ; 


a43079Cardnames ; 


a57131Cardnames ; 


a58953Cardnames ; 


a45105Cardnames ; 


a47775Cardnames ; 


a41825Cardnames ; 


a41501Cardnames ; 


a47108Cardnames ; 


a55659Cardnames ; 


a44572Cardnames ; 


a44183Cardnames ; 


"146756 | 2 
"162876 | 2 
"164633 | 2 
"146215 | 2 
"160450 | > 
"151010 | 2 
"164948 | > 
"143079 | 2 
"157131| 2 
"158953 | 2 
"145105 | 2 
"147775 | 7 
"141825 | 7 
"141501| 2 
"147108 | 7 
"155659 | 2 
“144572 7 


"144183 | 7 


Si vous voulez faire ceci a quelqu'un, assurez-vous que sa santé mentale est stable. 


A part les noms de fonction dans le fichier PDB, il ya de nombreux appels a la fonction 
Log() qui peuvent grandement aider, car le jeu Solitaire signale ce qu’il est en train 
de faire en ce moment. 


Devoir: essayer de supprimer quelques cartes ou le deux de tréfle. Et que se passe- 
t-il si nous échangeons les noms des cartes dans les tableaux de chaines? 


J'ai aussi essayé de passer des nombres comme 0, 0..50 à Card: Init() (pour avoir 
2 zéro dans une liste de 52 nombres). Ainsi, j'ai vu deux cartes deux de tréfle à un 
moment, mais le Solitaire avait un comportement erratique. 


Ceci est le Solitaire de Windows 7 modifié: Solitaire51.exe. 
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8.6.2 53 cartes 


Maintenant, regardons la premiére partie de la boucle: 


.text:0000000100036684 loc_100036684: ; CODE XREF: 7 
y SolitaireGame: :InitialDeal(void)+1C0j 
. text :0000000100036684 mov eax, 4EC4EC4Fh 
. text :0000000100036689 mul edi 
. text :000000010003668B mov r8d, edx 
. text :000000010003668E shr red, 4 ; unsigned 7 
& int 
.text:0000000100036692 mov eax, r8d 
.text:0000000100036695 imul eax, 52 
.text:0000000100036698 mov edx, edi 
.text:000000010003669A sub edx, eax ; unsigned 7 
& int 
.text:000000010003669C mov rcx, [rbx+128h] ; this 
.text:00000001000366A3 call 27 
V CreateCard@CardTable@@IEAAPEAVCard@@II@Z ; CardTable::CreateCard(uint/ 
S ,uint) 
.text:00000001000366A8 mov rdx, rax ; struct 7 
& Card * 
.text:00000001000366AB mov rcx, rbx ; this 
.text:00000001000366AE call 27 
y Push@CardStack@@QEAAXPEAVCard@@@Z ; CardStack: :Push(Card *) 
.text:00000001000366B3 inc edi 
.text:00000001000366B5 cmp edi, 52 
.text:00000001000366B8 jb short loc 100036684 


Qu'est-ce que cette multiplication par 4EC4EC4Fh? Il s'agit sûrement de la division 
par la multiplication. Et voici ce qu'Hex-Rays en dit: 


v5 = 0; 
do 


v6 = CardTable: :CreateCard(v4[37], v5 % 0x34, v5 / 0x34); 
CardStack: :Push((CardStack *)v4, v6); 
++V5; 

} 

while ( v5 < 0x34 ); 


D'une certaine facon, la fonction CreateCard() prend deux arguments: l'itérateur 
divisé par 52 et le reste de l'opération de division. Difficile de dire pourquoi ils ont fait 
ainsi. Le Solitaire ne peut pas permettre plus de 52 cartes, donc le dernier argument 
est absurde, il vaut toujours zéro. 


Mais une fois que j'ai modifié l'instruction cmp edi, 52 en 0x1000366B5 par cmp 
edi, 53, j'ai trouvé qu'il y avait maintenant 53 cartes. La derniére est le deux de 
tréfle, car il s'agit de la carte numérotée 0. 


Lors de la derniére itération, 0x52 est divisé par 0x52, le reste est zéro, donc la carte 
d'indice O est ajoutée deux fois. 


Que c'est frustrant, il y a deux deux de tréfle : 
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B Solitaire 3 inl x| 
Game Help 
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Pop! 
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Ceci est le Solitaire de Windows 7 modifié: Solitaire53.exe. 


8.7 Blague FreeCell (Windows 7) 


Ceci est une blague que j'ai fait une fois pour mes collégues qui jouaient trop au 
solitaire FreeCell. Pouvons-nous forcer FreeCell à jouer la méme partie à chaque 
fois? Comme, voyez-vous, dans le film "Groundhog Day" ? 


(J'écris ceci en novembre 2019. Il semble qu'IDA ne puisse obtenir les PDBs depuis 
les serveurs de Microsoft. Peut-étre que Windows 7 n'est plus supporté? En tout cas, 
je ne peux pas obtenir les noms de fonction...) 


8.7.1 Partie I 


Donc, j'ai chargé FreeCell.exe dans IDA et trouvé qu'à la fois rand(), srand() et time() 
sont importées depuis msvcrt.dll. time() est en effet utilisée comme valeur d'initiali- 
sation pour srand() : 


.text:01029612 sub 1029612 proc near ; CODE | 
XREF: sub 102615C+149 


1075 


.text:01029612 ; 
sub_1029DA6+67 


.text:01029612 8B FF mov edi, edi 
.text:01029614 56 push esi 

.text:01029615 57 push edi 

.text:01029616 6A 00 push 0 ; Time 
.text:01029618 8B F9 mov edi, ecx 
.text:0102961A FF 15 80 16 00+ call ds: time 

.text:01029620 50 push eax ; Seed 
.text:01029621 FF 15 84 16 00+ call ds:srand 
.text:01029627 8B 35 AC 16 00+ mov esi, ds: rand 
.text:0102962D 59 pop ecx 

.text:0102962E 59 pop ecx 

.text:0102962F FF D6 call esi ; rand 
.text:01029631 FF D6 call esi ; rand 
.text:01029633 

.text:01029633 loc 1029633: ; CODE 


XREF: sub_1029612+26 
.text:01029633 ; 
sub 1029612+2D 


.text:01029633 FF D6 call esi ; rand 
.text:01029635 83 F8 01 cmp eax, 1 
.text:01029638 7C F9 jt short loc 1029633 
.text:0102963A 3D 40 42 OF 00 cmp eax, 1000000 
.text:0102963F 7F F2 jg short loc 1029633 
.text:01029641 6A 01 push 1 

.text:01029643 50 push eax 
.text:01029644 8B CF mov ecx, edi 
.text:01029646 E8 2D F8 FF FF call sub 1028E78 
.text:0102964B 5F pop edi 
.text:0102964C 5E pop esi 
.text:0102964D C3 retn 

.text:0102964D sub 1029612 endp 


“In the morning you will send for a hansom, desiring your man to take neither the 
first nor the second which may present itself." ( The Memoirs of Sherlock Holmes, 
par Arthur Conan Doyle? ) 


Il y a un autre appel a la parie time() et srand(), mais mon tracer a montré que ceci 
est notre point d'intérét: 


tracer.exe -l:FreeCell.exe bpf=msvcrt.dll!time bpf=msvcrt.dll!srand,args:1 


TID-5340|(0) msvcrt.dll!time() (called from FreeCell.exe!BASE+0x29620 (0, 
& x209620)) 

TID-5340|(0) msvcrt.dll!time() -> 0x5ddb68aa 

TID-5340|(1) msvcrt.dll!srand(0x5ddb68aa) (called from FreeCell.exe!BASE«07 
Y x29627 (0x209627)) 

TID=5340| (1) msvcrt.dll!srand() -> 0x5507e0 

TID=5340|(1) msvcrt.dll!srand(0x399f) (called from FreeCell.exe!BASE+0 
y x27d3a (0x207d3a)) 


12http://www.gutenberg.org/files/834/834-0.txt 
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TID-5340|(1) msvcrt.dll!srand() -> 0x5507e0 


Vous voyez, la fonction time() a renvoyé Ox5ddb68aa et la méme valeur est utilisée 
comme un argument pour srand(). 


Essayons de forcer time() a toujours renvoyé 0: 


tracer.exe -l:FreeCell.exe bpf=msvcrt.dll!time,rt:0 bpfemsvcrt.dll!srand,7 
V args:1 


TID=2104| (0) msvcrt.dll!time() (called from FreeCell.exe!BASE+0x29620 (0, 
y xb19620)) 

TID=2104| (0) msvcrt.dll!time() -> Ox5ddb68f6 

TID=2104|(0) Modifying EAX register to 0x0 

TID=2104| (1) msvcrt.dll!srand(0x0) (called from FreeCell.exe!BASE+0x29627 7 
y (0xb19627)) 

TID=2104| (1) msvcrt.dll!srand() -> 0x3707e0 

TID=2104|(1) msvcrt.dll!srand(0x52f6) (called from FreeCell.exe! BASE+0/ 
y x27d3a (0xb17d3a)) 

TID=2104| (1) msvcrt.dll!srand() -> 0x3707e0 


Maintenant, je vois toujours le méme jeu à chaque fois que je lance FreeCell en 
utilisant tracer : 


Maintenant, comment modifier l'exécutable? 


Nous voulons passer 0 comme argument à srand() en 0x01029620. Mais il y a une 
instruction sur un octet: PUSH EAX. Or PUSH 0 est une instruction sur deux octets. 
Comment la faire tenir? 


Qui a-t-il dans les autres registres à ce moment? En utilisant tracer je les affiche tout: 


tracer.exe -l:FreeCell.exe bpx=FreeCell.exe!0x01029620 


TID=4448|(0) FreeCell.exe!0x1029620 

EAX=0x5ddb6ac4 EBX-0x00000000 ECX=0x00000000 EDX-0x00000000 
ESI-0x054732d0 EDI=0x054732d0 EBP=0x0020f2bc ESP=0x0020f298 
EIP-0x00899620 

FLAGS=PF ZF IF 

TID=4448|(0) FreeCell.exe!0x1029620 

EAX=0x5ddb6ac8 EBX=0x00000002 ECX=0x00000000 EDX-0x00000000 
ESI=0xffffff11 EDI=0x054732d0 EBP=0x0020da78 ESP=0x0020d9d4 
EIP-0x00899620 

FLAGS-PF ZF IF 

TID=4448|(0) FreeCell.exe!0x1029620 

EAX=0x5ddb6aca EBX=0x00000002 ECX=0x00000000 EDX-0x00000000 
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ESI-0x7740c460 EDI=0x054732d0 EBP-0x0020da78 ESP=0x0020d9d4 
EIP=0x00899620 
FLAGS=PF ZF IF 


Peu importe le nombre de fois que je redémaare le jeu, ECX et EDX semblent toujours 
contenir 0. Donc, j'ai modifié PUSH EAX à l'adress 0x01029620 en PUSH EDX (aussi 
une instruction sur 1 octet), et maintenant FreeCell montre toujours le méme jeu au 
joueur. 


Toutefois, d'autres options pourraient exister. En fait, nous n'avons pas besoin de 
passer 0 à srand(). Plutôt, nous voulons passer une constante à srand() pour que 
le jeu soit le méme à chaque fois. Comme on peut le voir, la valeur d'EDI n'a pas 
changé. Peut-étre que nous pourrions l'essayer aussi. 


Maintenant une modification un peu plus difficile. Ouvrons FreeCell.exe dans Hiew: 


Hiew: FreeCellexe 


p\FreeCell.exe 


Nous n'avons pas des place pour remplacer l'instruction d'un octet PUSH EAX avec 
celle sur deux octets PUSH 0. Et nous ne pouvons pas juste remplir CALL ds:time 
avec des NOPs, car il y a un FIXUP (adresse de la fonction time() dans msvcrt.dll). 
(Hiew a marqué ces 4 octets en gris.) Donc, voici ce que je fais: modifier les 2 pre- 
miers octets en EB 04. Ceci est un JMP pour contourner les 4 octets FIXUP. 
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Hiew: FreeCellexe 


Puis, je remplace PUSH EAX avec NOP. Ainsi, srand() aura son argument du PUSH 0 
au-dessus. Aussi, je modifie une des POP ECX en NOP, car j'ai supprimé un PUSH. 


Maintenant, le chargeur de Windows écrita le FIXUP de 4 octets en 0x0102961C, 
mais ca m'est égal: l'adresse de time() ne sera plus utilisée. 


8.7.2 Partie Il: casser le sous- menu Select Game 


L'utilisateur peut toujorus choisir des jeux différents dans le menu. Voyons si srand() 
est toujours appelée. J'essaye d'entrer 1/2/3 dans la boite de dialoue "Select Game": 


tracer.exe -l:FreeCell.exe bpf=msvcrt.dll!srand,args:1 


TID=4936| (0) 
S x29627 
TID=4936| (0) 
TID=4936| (0) 
y x27d3a 
TID=4936| (0) 


msvcrt.dli!srand(O0x5ddb6df9) (called from FreeCell.exe!BASE407 
(0xb49627)) 

msvcrt.dll!srand() -> 0x5907e0 

msvcrt.dll!srand(0x2b40) (called from FreeCell.exe!BASE407 
(0xb47d3a)) 

msvcrt.dll!srand() -> 0x5907e0 
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TID=4936|(0) msvcrt 
y (0xb47d3a)) 
TID=4936|(0) msvcrt 
TID=4936|(0) msvcrt 
y (0xb47d3a)) 
TID-4936|(0) msvcrt 
TID=4936|(0) msvcrt 
y (0xb47d3a)) 
TID=4936|(0) msvcrt 


.dll!srand(0x1) (called from FreeCell.exe!BASE+0x27d3a 7 


.dll!srand() -> 0x5907e0 
.dll!srand(0x2) (called from FreeCell.exe!BASE+0x27d3a 7 


.dll!srand() -> 0x5907e0 
.dll!srand(0x3) (called from FreeCell.exe!BASE+0x27d3a 7 


.dll!srand() -> 0x5907e0 


Oui, le nombre qu'entre l'utilisateur est simplement un argument pour srand(). Oü 


est-elle appelée? 


.text:01027CBA 


loc_1027CBA: ; 2 


& CODE XREF: sub\_1027AC6+179 


.text:01027CBA 83 FF FC cmp edi, OFFFFFFFCh 

.text:01027CBD 75 74 jnz short loc 1027D33 

.text:01027D33 loc 1027D33: ; 2 
Y CODE XREF: sub\_1027AC6+1F7 

.text:01027D33 57 push edi >y 
S Seed 

.text:01027D34 FF 15 84 16 00+ call ds:srand 

.text:01027D3A 59 pop ecx 

.text:01027D3B 6A 34 push 34h 

.text:01027D3D 5B pop ebx 

.text:01027D3E 33 C0 xor eax, eax 


Je n'ai pas pu modifier PUSH EDI d'un octet en PUSH 0 de deux octets. Mais je vois 
qu'il y seulement un unique saut à loc 1027D33 dans ce qui précéde. 


Je modifie CMP EDI, 


. en XOR EDI, EDI, en complétant le 3éme octet avec NOP. 


Je modifie aussi JNZ en JMP, afin que le saut se produise toujours. 


Maintenant FreeCell ignore le nombre entré par l'utilisateur, mais soudain, il y a le 


méme jeu au début: 
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-Dixi 


Game Help 


#19847 left: 52 y 


Il semble que le code que nous avons modifié dans la partie I est relié d'une certaine 
façon à du code aprés 0x01027CBD, qui s'exécute si EDI==OxFFFFFFFC. De toutes 
facons, notre but est atteint — le jeu est toujours le méme au début, et l'utilisateur 
ne peut pas en choisir un autre avec le menu. 


8.8 Dongles 


J'ai occasionnellement effectué des remplacements logiciel de dongle de protection 
de copie, ou «émulateur de dongle» et voici quelques exemples de comment ca 
s'est produit. 


À propos du cas avec Rocket et Z3, qui n'est pas présent ici, vous pouvez le lire là: 
http://yurichev.com/tmp/SAT SMT DRAFT.pdf. 


8.8.1 Exemple #1: MacOS Classic et PowerPC 
Il y a ici un exemple de programme pour MacOS Classic*3, pour PowerPC. La société 


qui a développé le logiciel a disparu il y a longtemps, donc le client (légal) avait peur 
d'un probléme matériel sur le dongle. 


13pre-UNIX MacOS 
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Lorsqu'on le lancait sans le dongle connecté, une boite de dialogue avec le message 
"Invalid Security Device” apparaissait. 


Par chance, cette chaíne de texte püt facilement étre trouvée dans le fichier exécu- 
table binaire. 


Prétendons que nous ne sommes pas trés familier, à la fois avec le Mac OS Classic 
et le PowerPC, mais essayons tout de méme. 


IDA ouvre le fichier exécutable sans probléme, indique son type comme "PEF (Mac OS 
or Be OS executable)" (en effet, c'est un format de fichier Mac OS Classic standard). 


En cherchant la chaîne de texte avec le message d'erreur, nous trouvons ce morceau 
de code: 


seg000:000C87FC 38 60 00 01 li *r3, 1 

seg000:000C8800 48 03 93 41 bl check1 

seg000:000C8804 60 00 00 00 nop 

seg000:000C8808 54 60 06 3F  clrlwi. %r0, %r3, 24 

seg000:000C880C 40 82 00 40 bne OK 

seg000:000C8810 80 62 9F D8 lwz *r3, TC aInvalidSecurityDevice 


Oui, ceci est du code PowerPC. 
Le CPU est un RISC 32-bit trés typique des années 1990s. 


Chaque instruction occupe 4 octets (tout comme MIPS et ARM) et les noms res- 
semblent quelque peu aux noms des instructions MIPS. 


check1() est une fonction donc nous allons donner le nom plu tard. BL est l'instruc- 
tion Branch Link, e.g., destinée à appeler des sous-programmes. 


Le point crucial est l'instruction BNE qui saute si la vérification du dongle de pro- 
tection passe ou pas si une erreur se produit: alors l'adresse de la chaîne de texte 
est chargée dans le registre r3 pour la passer à la routine de la boite de dialogue 
subséquente. 


Dans [Steve Zucker, SunSoft and Kari Karhi, IBM, SYSTEM V APPLICATION BINARY 
INTERFACE: PowerPC Processor Supplement, (1995)]!^nous trouvons que le registre 
r3 es utilisé pour la valeur de retour (et r4, dans le cas de valeurs 64-bit). 


Une autre instruction inconnue est CLRLWI. Dans [PowerPC(tm) Microprocessor Fa- 
mily: The Programming Environments for 32-Bit Microprocessors, (2000)]*>nous ap- 
prenons que cette instruction effectue la mise à zéro et le chargement. Dans notre 
cas, elle efface les 24 bits haut de la valeur dans r3 et la met dans rO, donc elle est 
analogue à MOVZX en x86 (1.23.1 on page 265), mais elle met aussi les flags, donc 
BNE peut ensuite les tester. 


Jetons un œil à la fonction check1() : 


1^Aussi disponible en http://yurichev.com/mirrors/PowerPC/elfspec ppc.pdf 
I^Aussi disponible en http: //yurichev.com/mirrors/PowerPC/6xx pem.pdf 
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seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 


:00101B40 
:00101B40 
:00101B40 
:00101B40 
:00101B40 
:00101B40 
:00101B44 
:00101B48 
:00101B4C 
:00101B50 
:00101B54 
:00101B58 
:00101B5C 
:00101B60 
:00101B60 


check1: 


.set arg 


# End of 


# CODE XREF: seg000:00063E7Cp 
+ sub_64070+160p ... 


| 8, 8 

mflr ro 

stw *sr0, arg 8(%sp) 

stwu %Sp, -0x40(%sp) 

bl check2 

nop 

lwz “ro, 0x40+arg_8(%sp) 
addi *ssp, “sp, 0x40 

mtlr ro 

blr 


function check1 


Comme on peut le voir dans IDA, cette fonction est appelée depuis de nombreux 
points du programme, mais seule la valeur du registre r3 est testée aprés chaque 


appel. 


Tout ce que fait cette fonction est d'appeler une autre fonction, donc c'est une fonc- 
tion thunk : il y a un prologue et un épilogue de fonction, mais le registre r3 n'est 
pas touché, donc checkl() renvoie ce que check2() renvoie. 


BLR** semble être le retour de la fonction, mais vu comment IDA dispose la fonction, 
nous ne devons probablement pas nous en occuper. 


Puisque c'est un RISC typique, il semble que les sous-programmes soient appelés 
en utilisant un registre de lien, tout comme en ARM. 


La fonction check2() est plus complexe: 


seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 


100118684 
100118684 
100118684 
100118684 
100118684 
100118684 
100118684 
1600118684 
100118684 
100118688 
:0011868C 
100118690 
1600118690 
160118694 
1600118698 
:0011869C 
:001186A0 
:001186A4 
:001186A8 
:001186AC 


check2: 


.set var 
.set var 
.set var 
.set var 
.set arg 


stw 
mflr 
lwz 
„using 
stw 
stw 

mr 

stw 
clrlwi 
cmplwi 
stwu 
bne 


16(PowerPC) Branch to Link Register 


# CODE XREF: check1+Cp 


18, -0x18 
C, -OxC 
8, -8 

_4, -4 

| 8, 8 


*sr31, var_4(%sp) 
ro 

%r31, off 1485E8 # dword 24B704 
dword 24B704, %r31 
%r30, var_8(%sp) 
*sr29, var C(%sp) 
%r29, %r3 

*sr0, arg 8(%sp) 
%r0, %r3, 24 

“ro, 1 

“sp, -0x50(%sp) 
loc_1186B8 
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seg000:001186B0 38 60 00 01 li %r3, 1 

seg000:001186B4 48 00 00 6C b exit 

seg000:001186B8 

seg000 :001186B8 loc 1186B8: £ CODE XREF: check2+28j 
seg000:001186B8 48 00 03 D5 bl sub 118A8C 
seg000:001186BC 60 00 00 00 nop 

seg000:001186CO 3B CO 00 00 li %r30, 0 

seg000:001186C4 

seg000:001186C4 skip: # CODE XREF: check2+94j 
seg000:001186C4 57 CO 06 3F  clrlwi. %r0, %r30, 24 
seg000:001186C8 41 82 00 18 beq loc 1186E0 
seg000:001186CC 38 61 00 38 addi %r3, %sp, Ox50+var 18 
seg000:001186D0 80 9F 00 00 lwz %r4, dword 24B704 
seg000:001186D4 48 00 CO 55 bl . RBEFINDNEXT 
seg000:001186D8 60 00 00 00 nop 

seg000:001186DC 48 00 00 1C b loc 1186F8 
seg000:001186E0 

seg000:001186E0 loc 1186E0: # CODE XREF: check2+44j 
seg000:001186E0 80 BF 00 00 lwz %r5, dword 24B704 
seg000:001186E4 38 81 00 38 addi %r4, %sp, Ox50+var 18 
seg000:001186E8 38 60 08 C2 li %r3, 0x1234 
seg000:001186EC 48 00 BF 99 bl . RBEFINDFIRST 
seg000:001186F0 60 00 00 00 nop 

seg000:001186F4 3B CO 00 01 li %r30, 1 

seg000:001186F8 

seg000:001186F8 loc 1186F8: £ CODE XREF: check2+58j 
seg000:001186F8 54 60 04 3F  clrlwi. %r0, %r3, 16 
seg000:001186FC 41 82 00 OC beq must jump 

seg000:00118700 38 60 00 00 li %r3, 0 # error 
seg000:00118704 48 00 00 1C b exit 

seg000:00118708 

seg000:00118708 must jump: # CODE XREF: check2+78j 
seg000:00118708 7F A3 EB 78 mr %r3, %r29 

seg000:0011870C 48 00 00 31 bl check3 


seg000:00118710 60 00 00 00 nop 
seg000:00118714 54 60 06 3F clrlwi. %r0, %r3, 24 


seg000:00118718 41 82 FF AC beq skip 

seg000:0011871C 38 60 00 01 li %r3, 1 
seg000:00118720 

seg000:00118720 exit: # CODE XREF: check2+30j 
seg000:00118720 # check2+80j 
seg000:00118720 80 01 00 58  lwz *sr0, Ox50+arg 8(%sp) 
seg000:00118724 38 21 00 50 addi “sp, %sp, 0x50 
seg000:00118728 83 El FF FC lwz *sr31, var_4(%sp) 
seg000:0011872C 7C 08 03 A6  mtlr %rQ 

seg000:00118730 83 C1 FF F8 lwz *sr30, var_8(%sp) 
seg000:00118734 83 Al FF F4 lwz *sr29, var_C(%sp) 
seg000:00118738 4E 80 00 20 blr 

seg000:00118738 # End of function check2 


Nous sommes encore chanceux: quelques noms de foncions ont été laissés dans 
l'exécutable (section de symboles de débogage? 
difficile à dire puisque nous ne sommes pas trés familier de ce format de fichier, 


1085 


peut-étre est-ce une sorte d'export PE? (6.5.2)), 
comme .RBEFINDNEXT() et . RBEFINDFIRST(). 


Enfin ces fonctions appellent d'autres fonctions avec des noms comme .GetNextDeviceViaUSB(), 
.USBSendPKT(), donc elles travaillent clairement avec un dispositif USB. 


Il y a méme une fonction appelée .GetNextEve3Device ( ) —qui semble familière, il 
y avait un dongle Sentinel Eve3 pour le port ADB (présent sue les MACs) dans les 
1990s. 


Regardons d'abord comment le registre r3 est mis avant le retour, en ignorant tout 
le reste. 


Nous savons qu'une «bonne » valeur de r3 doit étre non-nulle, r3 à zéro conduit à 
l'exécution de la partie avec un message d'erreur dans une boite de dialogue. 


Il y a deux instructions li %r3, 1 présentes dans la fonction etune li %r3, 0 (Load 
Immediate, i.e., charger une valeur dans un registre). La premiére instruction est en 
0x001186B0—et franchement, il est difficile de dire ce qu'elle signifie. 


Ce que l'on voit ensuite, toutefois, est plus facile à comprendre: . RBEFINDFIRST() 
est appelé: si elle échoue, O est écrit dans r3 et nous sautons à exit, autrement 
une autre fonction est appelée(check3())—si elle échoue aussi, .RBEFINDNEXT () 
est appelée, probablement afin de chercher un autre dispositif USB. 


N.B.: clrlwi. %r0, %r3, 16 est analogue à ce que nous avons déjà vu, mais elle 
éfface 16 bits, i.e., 
.RBEFINDFIRST() renvoie probablement une valeur 16-bit. 


B (signifie branch) saut inconditionnel. 
BEQ est l'instruction inverse de BNE. 


Regardons check3() : 


seg000:0011873C check3: # CODE XREF: check2+88p 
seg000:0011873C 

seg000:0011873C .set var 18, -0x18 
seg000:0011873C .set var C, -0xC 
seg000:0011873C .set var 8, -8 

seg000:0011873C .set var 4, -4 

seg000:0011873C .set arg 8, 8 

seg000:0011873C 

seg000:0011873C 93 E1 FF FC stw *sr31, var_4(%sp) 
seg000:00118740 7C 08 02 A6 mflr *srO 

seg000:00118744 38 AO 00 00 li %r5, 0 
seg000:00118748 93 C1 FF F8  stw %r30, var 8(%sp) 
seg000:0011874C 83 C2 95 A8 lwz *5r30, off 1485E8 # dword 24B704 
seg000:00118750 .using dword 24B704, %r30 
seg000:00118750 93 Al FF F4 stw *sr29, var C(%sp) 
seg000:00118754 3B A3 00 00 addi %r29, %r3, 0 
seg000:00118758 38 60 00 00 li %r3, 0 
seg000:0011875C 90 01 00 08  stw *sr0, arg 8(%sp) 
seg000:00118760 94 21 FF BO stwu “sp, -0x50(%sp) 
seg000:00118764 80 DE 00 00 lwz %r6, dword 24B704 
seg000:00118768 38 81 00 38 addi %r4, %sp, Ox50+var 18 
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seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
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seg000 
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seg000 
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seg000 
seg000 
seg000 
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seg000 
seg000 
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seg000 
seg000 
seg000 
seg000 
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seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 


:0011876C 
:00118770 
:00118774 
:00118778 
:0011877C 
:00118780 
:00118784 
:00118784 
:00118784 
:00118788 
:0011878C 
:00118790 
:00118794 
:00118798 
:00118798 
:00118798 
:0011879C 
:001187A0 
:001187A4 
:001187A8 
:001187AC 
:001187B0 
:001187B4 
:001187B8 
:001187BC 
:001187C0 
:001187C0 
:001187C0 
:001187C4 
:001187C8 
:001187CC 
:001187D0 
:001187D4 
:001187D4 
:001187D4 
:001187D8 
:001187DC 
:001187E0 
:001187E4 
:001187E8 
:001187EC 
:001187F0 
:001187F4 
:001187F8 
:001187F8 
:001187F8 
:001187FC 
:00118800 
:00118804 
:00118804 
:00118804 
:00118808 
:0011880C 


bl . RBEREAD 

nop 

clrlwi. %r0, %r3, 16 
beq loc 118784 
li %r3, 0 

b exit 


loc 118784: # CODE XREF: check3+3Cj 


lhz *srO, Ox50+var_18(%sp) 
cmplwi %r0, 0x1100 

beq loc 118798 

li %r3, 0 

b exit 


loc 118798: # CODE XREF: check3+50j 


lwz %r6, dword_24B704 
addi %r4, %sp, 0x50+var_18 
li %r3, 1 


li %r5, 0 

bl . RBEREAD 

nop 

clrlwi. %r0, %r3, 16 
beq loc_1187C0 
li %r3, 0 

b exit 


loc 1187C0: # CODE XREF: check3+78j 


lhz *srO, Ox50+var_18(%sp) 
cmplwi %r0, Ox09AB 

beq loc 1187D4 

li %r3, 0 

b exit 


loc 1187D4: # CODE XREF: check3+8Cj 


bl sub_B7BAC 
nop 

clrlwi %r0, %r3, 24 
cmpwi ?srO, 5 


beq loc 1188E4 
bge loc 1187F8 
cmpwi ?srO, 4 

bge loc 118848 
b loc 118980 


loc 1187F8: # CODE XREF: check3+ACj 


cmpwi %rQ, OxB 
beq loc 118804 
b loc 118980 


loc 118804: # CODE XREF: check3+C0j 


lwz %r6, dword 24B704 
addi %r4, %sp, Ox50+var 18 
li *r3, 8 
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seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
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seg000 
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seg000 
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seg000 
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100118810 
100118814 
100118818 
:0011881C 
:00118820 
:00118824 
:00118828 
:0011882C 
:0011882C 
:0011882C 
:00118830 
:00118834 
:00118838 
:0011883C 
:00118840 
:00118840 
:00118840 
:00118844 
:00118848 
:00118848 
:00118848 
:0011884C 
:00118850 
:00118854 
:00118858 
:0011885C 
:00118860 
:00118864 
:00118868 
:0011886C 
:00118870 
:00118870 
:00118870 
:00118874 
:00118878 
:0011887C 
:00118880 
:00118884 
:00118884 
:00118884 
:00118888 
:0011888C 
:00118890 
:00118894 
:00118898 
:00118898 
:00118898 
:0011889C 
:001188A0 
:001188A4 
:001188A8 
:001188AC 
:001188B0 


li 

bl 

nop 
clrlwi. 


li 
b 


%r5, 0 
. RBEREAD 


?srO, %r3, 16 
loc 11882C 
?sr3, 0 

exit 


loc 11882C: # CODE XREF: check3+E4j 


thz 


*srO, 0x50+var_18(%sp) 
%r0, OXFEAO 
loc_118840 

%r3, 0 

exit 


loc_118840: # CODE XREF: check3+F8j 


li 
b 


%r3, 1 
exit 


loc_118848: # CODE XREF: check3+B4j 


lwz 


nop 
clrlwi. 
beq 

li 

b 


%r6, dword 24B704 
%r4, %sp, Ox50+var 18 
%r3, OxA 

%r5, 0 

. RBEREAD 


?srO, %r3, 16 
loc_118870 
%r3, 0 

exit 


loc 118870: # CODE XREF: check3+1283 


lhz 
cmplwi 
beq 

li 

b 


*srO, Ox50+var_18(%sp) 
Sr0, OxA6E1 
loc_118884 

%r3, 0 

exit 


loc 118884: # CODE XREF: check3+13Cj 


clrlwi 
cmplwi 
bne 

li 

b 


%r31, %r29, 24 
%r31, 2 
loc_118898 
%r3, 1 

exit 


loc 118898: # CODE XREF: check3+150j 


lwz 
addi 
li 

li 

bl 

nop 
clrlwi. 


%r6, dword 24B704 
%r4, %sp, Ox50+var 18 
%r3, OxB 

%r5, 0 

. RBEREAD 


?srO, %r3, 16 
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seg000 
seg000 
seg000 
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seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
seg000 
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:001188B4 
:001188B8 
:001188BC 
:001188C0 
:001188C0 
:001188C0 
:001188C4 
:001188C8 
:001188CC 
:001188D0 
:001188D4 
:001188D4 
:001188D4 
:001188D8 
:001188DC 
:001188E0 
:001188E4 
:001188E4 
:001188E4 
:001188E8 
:001188EC 
:001188F0 
:001188F4 
:001188F8 
:001188FC 
:00118900 
:00118904 
:00118908 
:0011890C 
:0011890C 
:0011890C 
:00118910 
:00118914 
:00118918 
:0011891C 
:00118920 
:00118920 
:00118920 
:00118924 
:00118928 
:0011892C 
:00118930 
:00118934 
:00118934 
:00118934 
:00118938 
:0011893C 
:00118940 
:00118944 
:00118948 
:0011894C 
:00118950 
:00118954 


03 
94 
01 
90 


beq loc 1188C0 
li %r3, 0 
b exit 


loc 1188C0: # CODE XREF: check3+1783 


lhz *srO, Ox50+var_18(%sp) 
cmplwi %r0, 0x1C20 

beq loc_1188D4 

li *r3, 0 

b exit 


loc 1188D4: # CODE XREF: check3+18Cj 


cmplwi %r31, 3 


bne error 
li %r3, 1 
b exit 


loc_1188E4: # CODE XREF: check3+A8j 


lwz %r6, dword 24B704 
addi %r4, %sp, Ox50+var 18 
li *sr3, OxC 

li %r5, 0 

bl . RBEREAD 

nop 

clrlwi. %r0, %r3, 16 

beq loc 11890C 

li %r3, 0 

b exit 


loc 11890C: # CODE XREF: check3+1C4j 


lhz *srO, Ox50+var_18(%sp) 
cmplwi %rQ, 0x40FF 

beq loc 118920 

li %r3, 0 

b exit 


loc 118920: # CODE XREF: check3+1D8j 


clrlwi %r31, %r29, 24 
cmplwi %r31, 2 


bne loc 118934 
li %r3, 1 
b exit 


loc 118934: # CODE XREF: check3+1EC3 


lwz %r6, dword 24B704 
addi %r4, %sp, Ox50+var 18 
li %r3, OxD 

li %r5, 0 

bl . RBEREAD 

nop 

clrlwi. %r0, %r3, 16 

beq loc 11895C 

li %r3, 0 
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100118958 
:0011895C 
:0011895C 
:0011895C 
100118960 
100118964 
100118968 
:0011896C 
100118970 
100118970 
100118970 
100118974 
100118978 
:0011897C 
:00118980 
:00118980 
:00118980 
:00118980 
:00118984 
:00118988 
:0011898C 
:00118990 
:00118994 
:00118998 
:0011899C 
:001189A0 
:001189A4 
:001189A8 
:001189AC 
:001189AC 
:001189AC 
:001189B0 
:001189B4 
:001189B8 
:001189BC 
:001189C0 
:001189C0 
:001189C0 
:001189C4 
:001189C8 
:001189CC 
:001189D0 
:001189D0 
:001189D0 
:001189D0 
:001189D4 
:001189D8 
:001189DC 
:001189E0 
:001189E4 
:001189E8 
:001189EC 
:001189F0 


b exit 


loc 11895C: # CODE XREF: check3+214j 


thz *srO, 0x50+var_18(%sp) 
cmplwi %r0, OxFC7 

beq loc_118970 

li %r3, 0 

b exit 


loc_118970: # CODE XREF: check3+228j 


cmplwi %r31, 3 


bne error 
li %r3, 1 
b exit 


loc_118980: # CODE XREF: check3+B8j 


# check3+C4j 


lwz %r6, dword 24B704 
addi %r4, %sp, Ox50+var 18 
li %r31, 0 

li *sr3, 4 

li %r5, 0 

bl . RBEREAD 

nop 

clrlwi. %r0, %r3, 16 

beq loc 1189AC 

li %r3, 0 

b exit 


loc_1189AC: # CODE XREF: check3+264j 


thz *srO, 0x50+var_18(%sp) 
cmplwi %r0, OxAEDO 

bne loc 1189C0 

li %r31, 1 

b loc 1189D0 


loc 1189C0: # CODE XREF: check3+278j 


cmplwi %r0, 0x2818 


beq loc 1189D0 
li %r3, 0 
b exit 


loc_1189D0: # CODE XREF: check3+280j 


# check3+288j 
clrlwi %r0, %r29, 24 
cmplwi %r0, 2 


bne loc 1189F8 
clrlwi. %r0, %r31, 24 
beq good2 

bl sub 11D64C 
nop 

b exit 
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:001189F0 
:001189F0 
:001189F4 
:001189F8 
:001189F8 
:001189F8 
:001189FC 
:00118A00 
:00118A04 
:00118A08 
:00118A0C 
:00118A10 
:00118A14 
:00118A18 
:00118A1C 
:00118A20 
:00118A20 
:00118A20 
:00118A24 
:00118A28 
:00118A2C 
:00118A30 
:00118A34 
:00118A34 
:00118A34 
:00118A38 
:00118A3C 
:00118A40 
:00118A44 
:00118A44 
:00118A44 
:00118A44 
:00118A48 
:00118A4C 
:00118A50 
:00118A54 
:00118A58 
:00118A5C 
:00118A60 
:00118A64 
:00118A64 
:00118A64 
:00118A68 
:00118A6C 
:00118A6C 
:00118A6C 
:00118A6C 
:00118A70 
:00118A70 
:00118A70 
:00118A70 
:00118A74 
:00118A78 


38 


80 
38 
83 


60 


00 


00 


58 
50 
FC 


# CODE XREF: check3+2A4j 
%r3, 1 
exit 


loc 1189F8: # CODE XREF: check3+29Cj 


lwz 
addi 
li 

li 

bl 

nop 
clrlwi. 
beq 

li 

b 


%r6, dword 24B704 
%r4, %sp, Ox50+var 18 
%r3, 5 

%r5, 0 

. RBEREAD 


?srO, %r3, 16 
loc_118A20 
%r3, 0 

exit 


loc 118A20: # CODE XREF: check3+2D8j 


thz 
cmplwi 
bne 

li 

b 


*srO, 0x50+var_18(%sp) 
%r0, 0xD300 

loc 118A34 

%r31, 1 

good1 


loc 118A34: # CODE XREF: check3+2ECj 


cmplwi 
beq 
li 


error: 


exit: 


addi 
lwz 


%rQ, OXEBA1 
good1 

%r3, 0 

exit 


# CODE XREF: check3+2F4j 
# check3+2FCj 

?srO, %r29, 24 

%r0, 3 

error 


i. %r0, %r31, 24 


good 
sub 11D64C 


exit 


# CODE XREF: check3+318j 
%r3, 1 
exit 


# CODE XREF: check3+19Cj 
# check3+238j 
%r3, 0 


# CODE XREF: check3+44j 
# check3458j .. 

Sr0, Ox50+arg 8(%sp) 

“sp, *ssp, 0x50 

*sr31, var_4(%sp) 
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seg000:00118A7C 7C 08 03 A6  mtlr *srO 


seg000:00118A80 83 C1 FF F8 lwz %r30, var_8(%sp) 
seg000:00118A84 83 A1 FF F4 lwz *sr29, var_C(%sp) 
seg000:00118A88 4E 80 00 20 blr 

seg000:00118A88 # End of function check3 


Il y a de nombreux appels à .RBEREAD(). 


Peut-étre que la fonction renvoie une valeur du dongle, donc elles sont comparées 
ici avec des variables codées en dur en utilisant CMPLWI. 


Nous voyons aussi que le registre r3 est aussi rempli avant chaque appel à .RBEREAD() 
avec une de ces valeurs: 0,1, 8, OxA, OxB, OxC, OxD, 4, 5. Probablement une adresse 
mémoire ou quelque chose comme ca? 


Oui, en effet, en googlant ces noms de fonction il est facile de trouver le manuel du 
dongle Sentinel Eve3! 


Peut-étre n'avons nous pas besoin d'apprendre aucune autre instruction PowerPC: 
tout ce que fait cette fonction est seulement d'appeler .RBEREAD(), de comparer 
ses résultats avec les constantes et de renvoyer 1 si les comparaisons sont justes 
ou 0 autrement. 


Ok, tout ce dont nous avons besoin est que la fonction check1() renvoie toujours 1 
ou n'importe quelle valeur autre que zéro. 


Mais puisque nous ne sommes pas trés sûrs de nos connaissances des instructions 
PowerPC, nous allons étre prudents: nous allons patcher le saut dans check2() en 
0x001186FC et en 0x00118718. 


En 0x001186FC nous allons écrire les octets 0x48 et 0, convertissant ainsi l'instruc- 
tion BEQ en un B (saut inconditionnel) : nous pouvons repérer son opcode sans méme 
nous référer à [PowerPC(tm) Microprocessor Family: The Programming Environments 
for 32-Bit Microprocessors, (2000)1?”. 


En 0x00118718 nous allons écrire 0x60 et 3 octets à zéro, la convertissant ainsi en 
une instruction NOP : Nous pouvons aussi repérer son opcode dans le code. 


Et maintenant, tout fonctionne sans un dongle connecté. 


En résumé, des petites modification telles que celles-ci peuvent étre effectuées avec 
IDA et un minimum de connaissances en langage d'assemblage. 


8.8.2 Exemple +2: SCO OpenServer 


Un ancien logiciel pour SCO OpenServer de 1997 développé par une société qui a 
disparue depuis longtemps. 


Il y a un driver de dongle special à installer dans le système, qui contient les chaînes 
de texte suivantes: «Copyright 1989, Rainbow Technologies, Inc., Irvine, CA » et «Sen- 
tinel Integrated Driver Ver. 3.0 ». 


17Aussi disponible en http: //yurichev.com/mirrors/PowerPC/6xx pem.pdf 
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Après l'installation du driver dans SCO OpenServer, ces fichiers apparaissent dans 
l'arborescence /dev: 


/dev/rbst8 
/dev/rbsl9 
/dev/rbs110 


Le programme renvoie une erreur lorsque le dongle n'est pas connecté, mais le 
message d'erreur n'est pas trouvé dans les exécutables. 


Gráce à IDA, il est facile de charger l'exécutable COFF utilisé dans SCO OpenServer. 


Essayons de trouver la chaine «rbsl » et en effet, elle se trouve dans ce morceau de 
code: 


.text:00022AB8 public SSQC 

.text:00022AB8 SSQC proc near ; CODE XREF: SS0+7p 
.text:00022AB8 

.text:00022AB8 var 44 - byte ptr -44h 
.text:00022AB8 var 29 - byte ptr -29h 


.text:00022AB8 arg 0 dword ptr 8 
.text:00022AB8 

.text:00022AB8 push ebp 
.text:00022AB9 mov ebp, esp 
.text:00022ABB sub esp, 44h 
.text:00022ABE push edi 
.text:00022ABF mov edi, offset unk 4035D0 
.text:00022AC4 push esi 
.text:00022AC5 mov esi, [ebp+arg 0] 
.text:00022AC8 push ebx 
.text:00022AC9 push esi 
.text:00022ACA call strlen 
.text:00022ACF add esp, 4 
.text:00022AD2 cmp eax, 2 
.text:00022AD7 jnz loc 22BA4 
.text:00022ADD inc esi 
.text:00022ADE mov al, [esi-1] 
.text:00022AE1 movsx eax, al 

. text: 00022AE4 cmp eax, '3' 

. text: 00022AE9 jz loc 22B84 
.text:00022AEF cmp eax, '4' 
.text:00022AF4 jz loc 22B94 
.text:00022AFA cmp eax, '5' 
.text:00022AFF jnz short loc 22B6B 
.text:00022B01 movsx ebx, byte ptr [esi] 
.text:00022B04 sub ebx, '0' 
.text:00022B07 mov eax, 7 
.text:00022B0C add eax, ebx 
.text:00022BOE push eax 

.text :00022B0F lea eax, [ebp+var_44] 
.text:00022B12 push offset aDevSlD ; "/dev/sl%d" 
.text:00022B17 push eax 
.text:00022B18 call nl sprintf 


.text:00022B1D push 0 ENT 
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text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022B37 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022B57 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022B70 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022B84 


.text 


.text: 
.text: 
.text: 
.text: 


00022B1F 
00022B24 
00022B29 
00022B2C 
00022B31 
00022B33 
00022B36 


00022B3A 
00022B3F 
00022B40 
00022B45 
00022B48 
00022B48 
00022B48 
00022B4A 
00022B4C 
00022B4E 
00022B4F 
00022B54 
00022B57 
00022B57 


00022B59 
00022B5C 
00022B5D 
00022B62 
00022B65 
00022B67 
00022B69 
00022B6B 
00022B6B 
00022B6B 


00022B71 
00022B72 
00022B73 
00022B75 
00022B76 
00022B78 
00022B78 
00022B78 
00022B79 
00022B7A 
00022B7B 
00022B7D 
00022B7F 
00022B80 


00022B84 
00022B84 
00022B86 
00022B87 


push offset aDevRbsl8 
call access 
add esp, 14h 
cmp eax, OFFFFFFFFh 
jz short loc 22B48 
lea eax, [ebx+7] 
push eax 
lea eax, [ebp+var 44] 
push offset aDevRbslD 
push eax 
call nl sprintf 
add esp, OCh 
loc 22B48: ; CODE XREF: SSQC+79j 
mov edx, [edi] 
test edx, edx 
jte short loc 22B57 
push edx ; 
call | close 
add esp, 4 
loc 22B57: ; CODE XREF: SSQC+94j 
push 2 ; 
lea eax, [ebp+var 44] 
push eax ; 
call open 
add esp, 8 
test eax, eax 
mov [edi], eax 
jge short loc 22B78 
loc 22B6B: ; CODE XREF: SSQC+47j 
mov eax, OFFFFFFFFh 
pop ebx 
pop esi 
pop edi 
mov esp, ebp 
pop ebp 
retn 
loc 22B78: ; CODE XREF: SSQC+B1j 
pop ebx 
pop esi 
pop edi 
xor eax, eax 
mov esp, ebp 
pop ebp 
retn 
loc 22B84: ; CODE XREF: SSQC+31)j 
mov al, [esi] 
pop ebx 


pop esi 


; char * 


; "/dev/rbsl%d" 


int 


int 


char * 
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text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022B94 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022BAD 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022BD4 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:00022BF4 


.text 


.text: 
.text: 
.text: 
.text: 


00022B88 
00022B89 
00022B8E 
00022B90 
00022B92 
00022B93 
00022B94 


00022B94 
00022B96 
00022B97 
00022B98 
00022B99 
00022B9E 
00022BA0 
00022BA2 
00022BA3 
00022BA4 
00022BA4 
00022BA4 
00022BAB 
00022BAC 


00022BB4 
00022BB5 
00022BB8 
00022BBD 
00022BBE 
00022BC3 
00022BC6 
00022BC7 
00022BCC 
00022BCF 


00022BD6 
00022BDA 
00022BDA 
00022BDA 
00022BDD 
00022BDE 
00022BE3 
00022BE4 
00022BE7 
00022BE8 
00022BEA 
00022BEB 
00022BF0 
00022BF3 


00022BF5 
00022BF6 
00022BF8 
00022BF9 


pop edi 
mov ds:byte 407224, al 
mov esp, ebp 
xor eax, eax 
pop ebp 
retn 

loc 22B94: ; CODE XREF: SSQC+3Cj 
mov al, [esi] 
pop ebx 
pop esi 
pop edi 
mov ds:byte 407225, al 
mov esp, ebp 
xor eax, eax 
pop ebp 
retn 

loc 22BA4: ; CODE XREF: SSQC+1Fj 
movsx eax, ds:byte 407225 
push esi 
push eax 
movsx eax, ds:byte 407224 
push eax 
lea eax, [ebp+var 44] 
push offset a46CCs ; "40%C%C%S " 
push eax 
call nl sprintf 
lea eax, [ebp+var 44] 
push eax 
call strlen 
add esp, 18h 
cmp eax, 1Bh 
jle short loc 22BDA 
mov [ebp+var_29], 0 

loc 22BDA: ; CODE XREF: SSQC+11Cj 
lea eax, [ebp+var 44] 
push eax 
call strlen 
push eax ; unsigned int 
lea eax, [ebp+var 44] 
push eax ; void * 
mov eax, [edi] 
push eax ; int 
call _write 
add esp, 10h 
pop ebx 
pop esi 
pop edi 
mov esp, ebp 
pop ebp 
retn 
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. text 


:00022BFA 
.text:00022BFA SSQC 


db 0Eh dup(90h) 


endp 


Oui, en effet, le programme doit communiquer d'une facon ou d'une autre avec le 


driver. 


Le seul endroit oü la fonction SSQC() est appelée est dans la fonction thunk : 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


0000DBE8 
0000DBE8 SSQ 
0000DBE8 
0000DBE8 


0000DBE8 arg_0 


0000DBE8 
0000DBE8 
0000DBE9 
0000DBEB 
0000DBEE 
0000DBEF 
0000DBF4 
0000DBF7 
0000DBF9 
0000DBFA 
0000DBFB SSQ 


public SSQ 
proc near ; CODE XREF: 
; Sys info+CBp ... 


sys info+A9p 


- dword ptr 8 
push ebp 

mov ebp, esp 
mov edx, [ebp+arg 0] 
push edx 

call SSQC 

add esp, 4 
mov esp, ebp 
pop ebp 

retn 

endp 


SSQ() peut étre appelé depuis au moins 2 fonctions. 


L'une d'entre elles est: 


.data:0040169C 51 52 53 


DATA XREF: init sys+392r 
:0040169C | 
:0040169C 

CONTINUE: 
.data:004016A0 
:004016A4 
:004016A8 


.data 
.data 


.data 
.data 


"n 


.data:004016B8 3C or 3E 


sys info:loc D67Br 
:004016B8 
:004016BC 


.data 
.data 


dd offset aPressAnyKeyT 0 ; 


dd offset 
dd offset 
dd offset 


dd offset 


dd offset 


; these names we gave to the labels: 
.data:004016C0 answersl 
sys info+E7r 


.data 


:004016C4 


.data:004016C8 answers2 
sys info+F2r 


.data 


:004016CC 


.data:004016D0 C and B 
sys info+BAr 


.data 


:004016D0 


dd 6B05h 


dd 3D87h 
dd 3Ch 


dd 832h 
db OCh 


a51 
a52 
a53 


a3c 


a3e 


; Sys info+Alr 
; "PRESS ANY KEY TO 


: "51" 
s "52" 
: "53" 


; DATA XREF: 
: uci 
: "JE" 
; DATA XREF: 


; DATA XREF: 


; DATA XREF: 


; Sys info:OKr 
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.data:004016D1 byte 4016D1 
DATA XREF: sys info+FDr 
.data:004016D2 


.text:0000D652 
.text:0000D654 
.text:0000D659 
.text:0000D660 
.text:0000D661 
.text:0000D666 
.text:0000D669 
.text:0000D66E 
.text:0000D670 
.text:0000D672 
.text:0000D677 
.text:0000D679 
.text:0000D67B 
.text:0000D67B 
.text:0000D67B 
.text:0000D682 
.text:0000D683 
.text:0000D688 
.text:0000D68D 
.text:0000D692 
.text:0000D697 
.text:0000D69C 
.text:0000D69F 
.text:0000D6A6 
.text:0000D6A8 
.text:0000D6AA 
.text:0000D6B1 
. text : 0000D6B3 
. text: 0000D6B5 
.text : 0000D6BB 
.text : 0000D6BC 
. text: 0000D6BE 
.text:0000D6C0 
.text:0000D6CO0 
.text:0000D6CO0 
.text:0000D6C6 
.text:0000D6C8 
.text:0000D6CD 
.text:0000D6CF 
.text:0000D6D1 
.text:0000D6D1 loc D6D1: ; 
.text:0000D6D1 5 
.text:0000D6D1 

.text : 0000D6D4 

. text: 0000D6D5 

. text: 0000D6D8 

.text:0000D6DB 

.text : 0000D6E1 


loc D67B: ; 


loc D6C0: ; 


db 0Bh 
db 


xor 
mov 
mov 
push 
call 
add 
cmp 
jz 
xor 
mov 
test 
jz 


CODE XREF: 
mov 
push 
call 
push 
call 


CODE XREF: 
inc 
xor 
mov 
cmp 
jte 


CODE XREF: 


0 


eax, eax 
al, ds:ctl port 

ecx, 51 52 53[eax*4] 
ecx 

SSQ 

esp, 4 

eax, OFFFFFFFFh 

short loc D6D1 


ebx, ebx 
al, C and B 
al, al 


short loc D6CO 


sys info+106j 

eax, 3C or 3E[ebx*4] 
eax 

SSQ 

offset a4g ; 
SSQ 

offset a0123456789 ; 
SSQ 

esp, OCh 

edx, answersl[ebx*4] 
eax, edx 

short OK 

ecx, answers2[ebx*4] 
eax, ecx 

short OK 

al, byte 4016D1[ebx] 
ebx 

al, al 

short loc D67B 


"AG " 


"0123456789" 


sys info+C1j 
ds:ctl_port 
eax, eax 

al, ds:ctl_port 
eax, edi 

short loc_D652 


sys info-98j 


sys info-B6j 


mov 
inc 
mov 
cmp 
jte 


edx, [ebp+var 8] 
edx 

[ebp+var 8], edx 
edx, 3 

loc D641 
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.text:0000D6E1 loc_D6E1: ; CODE XREF: sys info+16j 


.text:0000D6E1 ; Sys info+51j 

.text:0000D6E1 pop ebx 
.text:0000D6E2 pop edi 
.text:0000D6E3 mov esp, ebp 
.text:0000D6E5 pop ebp 
.text:0000D6E6 retn 

.text:0000D6E8 OK: ; CODE XREF: sys info+F0)j 
.text:0000D6E8 ; Sys info+FBj 

.text:0000D6E8 mov al, C and B[ebx] 
.text:0000D6EE pop ebx 
.text:0000D6EF pop edi 
.text:0000D6F0 mov ds:ctl model, al 
.text:0000D6F5 mov esp, ebp 
.text:0000D6F7 pop ebp 
.text:0000D6F8 retn 

.text:0000D6F8 sys info endp 


« 3C» et « 3E» semblent familiers: il y avait un dongle Sentinel Pro de Rainbow sans 
mémoire, fournissant seulement une fonction de crypto-hachage secréte. 


Vous pouvez lire une courte description de la fonction de hachage dont il s'agit ici: 
2.5 on page 589. 


Mais retournons au programme. 


Donc le programme peut seulement tester si un dongle est connecté ou s'il est ab- 
sent. 


Aucune autre information ne peut étre écrite dans un tel dongle, puisqu'il n'a pas 
de mémoire. Les codes sur deux caractéres sont des commandes (nous pouvons 
voir comment les commandes sont traitées dans la fonction SSQC()) et toutes les 
autres chaínes sont hachées dans le dongle, transformées en un nombre 16-bit. L'al- 
gorithme était secret, donc il n'était pas possible d'écrire un driver de remplacement 
ou de refaire un dongle matériel qui l'émulerait parfaitement. 


Toutefois, il est toujours possible d'intercepter tous les accés au dongle et de trouver 
les constantes auxquelles les résultats de la fonction de hachage sont comparées. 


Mais nous devons dire qu'il est possible de construire un schéma de logiciel de pro- 
tection de copie robuste basé sur une fonction secréte de hachage cryptographique: 
il suffit qu'elle chiffre/déchiffre les fichiers de données utilisés par votre logiciel. 


Mais retournons au code: 


Les codes 51/52/53 sont utilisés pour choisir le port imprimante LPT. 3x/4x sont 
utilisés pour le choix de la «famille» (c'est ainsi que les dongles Sentinel Pro sont 
différenciés les uns des autres: plus d'un dongle peut étre connecté sur un port LPT). 


La seule chaine passée à la fonction qui ne fasse pas 2 caractéres est "0123456789". 
Ensuite, le résultat est comparé à l'ensemble des résultats valides. 
Si il est correct, OxC ou OxB est écrit dans la variable globale ctl model. 
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Une autre chaíne de texte qui est passée est "PRESS ANY KEY TO CONTINUE: ”, mais 
le résultat n'est pas testé. Difficile de dire pourquoi, probablement une erreur!?. 


Voyons ou la valeur de la variable globale ctl model est utilisée. 


Un tel endroit est: 


.text:0000D708 prep sys proc near ; CODE XREF: init sys+46Ap 
.text:0000D708 

.text:0000D708 var 14 
.text:0000D708 var 10 


dword ptr -14h 
byte ptr -10h 


.text:0000D708 var 8 dword ptr -8 
.text:0000D708 var 2 word ptr -2 
.text:0000D708 
.text:0000D708 push ebp 
.text:0000D709 mov eax, ds:net env 
.text:0000D70E mov ebp, esp 
.text:0000D710 sub esp, 1Ch 
.text:0000D713 test eax, eax 
.text:0000D715 jnz short loc D734 
.text:0000D717 mov al, ds:ctl model 
.text:0000D71C test al, al 
.text:0000D71E jnz short loc D77E 
.text:0000D720 mov [ebp+var_8], offset aleCvulnvvOkgT ; 
"Te-cvulnvV\\\bOKG]T " 
.text:0000D727 mov edx, 7 
.text:0000D72C jmp loc D7E7 


.text:0000D7E7 loc D7E7: ; CODE XREF: prep sys+24j 


.text:0000D7E7 ; prep sys+33j 
.text:0000D7E7 push edx 

.text:0000D7E8 mov edx, [ebp+var_8] 
.text:0000D7EB push 20h 

.text:0000D7ED push edx 

.text:0000D7EE push 16h 

.text:0000D7F0 call err warn 
.text:0000D7F5 push offset station sem 
.text:0000D7FA call ClosSem 
.text:0000D7FF call startup err 


Si c'est 0, un message d'erreur chiffré est passé à une routine de déchiffrement et 
affiché. 


La routine de déchiffrement de la chaine semble étre un simple xor : 


.text:0000A43C err warn proc near ; CODE XREF: 
prep sys+E8p 
. text: 0000A43C ; prep sys2+2Fp ... 


. text: 0000A43C 
.text:0000A43C var 55 
.text:0000A43C var 54 


byte ptr -55h 
byte ptr -54h 


18C'est un sentiment étrange de trouver un bug dans un logiciel aussi ancien. 
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.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0000A43F 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


0000A43C arg 0 
0000A43C arg 4 
0000A43C arg 8 
0000A43C arg C 
0000A43C 
0000A43C 
0000A43D 


00004442 
00004443 
00004446 
00004448 
0000A44A 
0000A44B 
0000A44D 
0000A450 
0000A453 
0000A453 loc A453: 


err warn+28j 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


: 00004453 


00004455 
00001458 
0000A45A 
0000A45D 
0000A45E 
0000A460 
0000A464 
0000A466 
0000A466 loc A466: 


err warn-Fj 


.text: 
:0000A46B 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


0000A466 


0000A46E 
0000A473 
0000A475 
0000A478 
0000A479 
0000A47E 
0000A481 
00004481 loc A481: 


err warn+72)j 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


0000A481 
0000A483 
0000A485 
0000A488 
0000A489 
0000A48E 
00004493 
00004496 
00004497 
00004498 
0000A49A 
0000A49B 
0000A49C 


ptr 8 

ptr OCh 
ptr 10h 
ptr 14h 


ebp 

ebp, esp 

esp, 54h 

edi 

ecx, [ebp+arg_8] 

edi, edi 

ecx, ecx 

esi 

short loc A466 

esi, [ebp+arg C] ; key 
edx, [ebp+arg 4] ; string 


; CODE XREF: 


eax, eax 
al, [edx+edi] 

eax, esi 

esi, 3 

edi 

edi, ecx 
[ebp+edi+var 55], al 
short loc A453 


; CODE XREF: 


[ebp+edi+var 54], 0 
eax, [ebptarg 0] 
eax, 18h 

short loc A49C 

eax, [ebp+var 54] 


eax 
status line 
esp, 4 
; CODE XREF: 
50h 
0 
eax, [ebp+var_54] 
eax 
memset 
pcv_refresh 
esp, OCh 
esi 
edi 
esp, ebp 
ebp 
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.text:0000A49C loc A49C: 
err warn-37j 
.text:0000A49C 
.text:0000A49E 
.text:0000A4A1 
. text: 0000A4A4 
. text: 0000A4A5 
.text:0000A4A6 
.text:0000A4AB 
.text:0000A4AE 
.text:0000A4AE err warn 


push 
lea 
mov 
push 
push 
call 
add 
jmp 
endp 


; CODE XREF: 


0 

eax, [ebp+var 54] 
edx, [ebp+arg 0] 
edx 

eax 

pcv lputs 

esp, OCh 

short loc A481 


C'est pourquoi nous étions incapable de trouver le message d'erreur dans les fichiers 
exécutable, car ils sont chiffrés (ce qui est une pratique courante). 


Un autre appel à la fonction de hachage SSQ() lui passe la chaine «offln» et le 
résultat est comparé avec OxFE81 et 0x12A9. 


Si ils ne correspondent pas, ca se comporte comme une sorte de fonction timer() 
(peut-étre en attente qu'un dongle mal connecté soit reconnecté et re-testé?) et 
ensuite déchiffre un autre message d'erreur à afficher. 


.text:0000DA55 loc DA55: 
sync _sys+24Cj 
.text:0000DA55 
.text:0000DA5A 
.text:0000DA5F 
.text:0000DA62 
.text:0000DA64 
.text:0000DA66 
.text:0000DA69 
.text:0000DA6B 
.text:0000DA71 
.text:0000DA77 
.text:0000DA7D 
.text:0000DA83 
.text:0000DA83 loc DA83: 
sync _sys+201j 
.text:0000DA83 
.text:0000DA85 
.text : 0000DA88 
. text: 0000DA8A 
. text: 0000DA90 
. text : 0000DA96 
. text: 0000DA99 
.text:0000DA9F 
.text:0000DA9F loc DA9F: 
sync sys+220j — 
.text:0000DA9F 
.text:0000DAA2 
. text: 0000DAA4 
. text: 0000DAA6 
. text: 0000DAA8 
.text:0000DAAD 
.text:0000DABO 


push 
call 
add 


; CODE XREF: 


offset a0ffln ; "offln" 
SSQ 

esp, 4 

dl, [ebx] 

esi, eax 

dl, OBh 

short loc DA83 
esi, OFE81h 

OK 

esi, OFFFFF8EFh 
OK 


; CODE XREF: 


cl, [ebx] 

cl, OCh 

short loc DA9F 
esi, 12A9h 

OK 

esi, OFFFFFFF5h 
OK 


; CODE XREF: 


eax, [ebp+var_18] 
eax, eax 

short loc DABO 
24h 

timer 

esp, 4 
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; this name we gave to label: 


.text:0000DABO loc DABO: ; CODE XREF: 
sync _sys+23Cj 

.text:0000DABO inc edi 

.text:0000DAB1 cmp edi, 3 

.text:0000DABA jte short loc DA55 

. text: 0000DAB6 mov eax, ds:net_env 

.text:0000DABB test eax, eax 

.text:0000DABD jz short error 

.text:0000DAF7 error: ; CODE XREF: 
sync sys+255)j 

.text:0000DAF7 ; Sync sys+274j 

.text:0000DAF7 mov [ebp+var 8], offset 2 
s encrypted error message2 

.text:0000DAFE mov [ebp+var C], 17h ; decrypting key 

.text:0000DB05 jmp decrypt end print message 

; this name we gave to label: 

.text:0000D9B6 decrypt end print message: ; CODE XREF: 
sync _sys+29Dj 

.text:0000D9B6 ; Sync sys+2AB)j 

.text:0000D9B6 mov eax, [ebp+var_18] 

.text:0000D9B9 test eax, eax 

.text:0000D9BB jnz short loc D9FB 

.text:0000D9BD mov edx, [ebp+var_C] ; key 

.text:0000D9CO mov ecx, [ebp+var 8] ; string 

.text:0000D9C3 push edx 

. text: 0000D9C4 push 20h 

. text: 0000D9C6 push ecx 

. text: 0000D9C7 push 18h 

. text: 0000D9C9 call err_warn 

. text: 0000D9CE push OFh 

. text: 0000D9D0 push 190h 

. text :0000D9D5 call sound 

. text: 0000D9DA mov [ebp+var_18], 1 

. text: 0000D9E1 add esp, 18h 

. text: 0000D9E4 call pcv_kbhit 

. text: 0000D9E9 test eax, eax 

. text: 0000D9EB jz short loc D9FB 


.data:00401736 encrypted error message2 db 74h, 72h, 78h, 43h, 48h, 6, 5Ah,7 


y 49h, 4Ch, 2 dup(47h) 
.data: 
& 33h, 36h, 76h 
.data: 


00401736 


00401736 


V 1Ah 


db 51h, 4Fh, 47h, 61h, 20h, 22h, 3Ch, 24h, 


db 3Ah, 33h, 31h, 0Ch, 0, 0Bh, 


r4 


lFh, 7, 1Eh, 2 
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Passer outre le dongle est assez facile: il suffit de patcher tous les sauts aprés les 
instructions CMP pertinentes. 


Une autre option est d'écrire notre propre driver SCO OpenServer, contenant une 
table de questions et de réponses, toutes celles qui sont présentent dans le pro- 
gramme. 


Déchiffrer les messages d'erreur 


À propos, nous pouvons aussi essayer de déchiffrer tous les messages d'erreurs. 
L'algorithme qui se trouve dans la fonction err warn() est trés simple, en effet: 


Listing 8.5 : Decryption function 


.text:0000A44D mov esi, [ebp+arg C] ; clef 

. text: 0000A450 mov edx, [ebp+arg 4] ; chaîne 

.text:0000A453 loc A453: 

.text:0000A453 xor eax, eax 

.text:0000A455 mov al, [edx«edi] ; charger l'octet 
chiffré . 

.text:0000A458 xor eax, esi ; le déchiffré 

.text:0000A45A add esi, 3 ; changé la clef pour 
l'octet suivant 

.text:0000A45D inc edi 

.text:0000A45E cmp edi, ecx 

.text:0000A460 mov [ebp+edi+var 55], al 

. text: 00001464 jl short loc A453 


Comme on le voit, non seulement la chaine est transmise à la fonction de déchiffre- 
ment mais aussi la clef: 


.text:0000DAF7 error: ; CODE XREF: 

sync Sys4255j 
.text:0000DAF7 ; Sync sys+274j 
.text:0000DAF7 mov [ebp+var 8], offset 2 

ú encrypted error message2 
.text:0000DAFE mov [ebp+var C], 17h ; decrypting key 
.text:0000DB05 jmp decrypt end print message 


; this name we gave to label manually: 


.text:0000D9B6 decrypt end print message: ; CODE XREF: 
sync _sys+29Dj 

.text:0000D9B6 ; Sync sys+2ABj 

.text:0000D9B6 mov eax, [ebp+var_18] 

.text:0000D9B9 test eax, eax 

.text:0000D9BB jnz short loc D9FB 

.text:0000D9BD mov edx, [ebp+var_C] ; key 

.text:0000D9CO mov ecx, [ebp+var_8] ; string 

. text: 0000D9C3 push edx 

. text: 0000D9C4 push 20h 

. text: 0000D9C6 push ecx 

. text: 0000D9C7 push 18h 


. text: 0000D9C9 call err_warn 
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L'algorithme est un simple xor : chaque octet est xoré avec la clef, mais la clef est 
incrémentée de 3 aprés le traitement de chaque octet. 


Nous pouvons écrire un petit script Python pour vérifier notre hypothése: 


Listing 8.6 : Python 3.x 


#!/usr/bin/python 
import sys 


msg=[0x74, 0x72, 0x78, 0x43, 0x48, 0x6, 0x5A, 0x49, Ox4C, 0x47, 0x47, 
0x51, Ox4F, 0x47, 0x61, 0x20, 0x22, Ox3C, 0x24, 0x33, 0x36, 0x76, 
Ox3A, 0x33, 0x31, 0x0C, 0x0, Ox0B, Ox1F, 0x7, Ox1E, 0x1A] 


key=0x17 

tmp=key 

for i in msg: 
sys.stdout.write ("*sc" % (i^tmp)) 
tmp=tmp+3 

sys.stdout.flush() 


Et il affiche: «check security device connection ». Donc oui, ceci est le message dé- 
chiffré. 


Il y a d'autres messages chiffrés, avec leur clef correspondante. Mais inutile de dire 
qu'il est possible de les déchiffrer sans leur clef. Premiérement, nous voyons que 
le clef est en fait un octet. C'est parce que l'instruction principale de déchiffrement 
(XOR) fonctionne au niveau de l'octet. La clef se trouve dans le registre ESI, mais 
seulement une partie de ESI d'un octet est utilisée. Ainsi, une clef pourrait étre plus 
grande que 255, mais sa valeur est toujours arrondie. 


En conséquence, nous pouvons simplement essayer de brute-forcer, en essayant 
toutes les clefs possible dans l'intervalle 0..255. Nous allons aussi écarter les mes- 
sages comportants des caractéres non-imprimable. 


Listing 8.7 : Python 3.x 


#!/usr/bin/python 
import sys, curses.ascii 


msgs-[ 

[0x74, 0x72, 0x78, 0x43, 0x48, 0x6, 0x5A, 0x49, Ox4C, 0x47, 0x47, 
0x51, Ox4F, 0x47, 0x61, 0x20, 0x22, 0x3C, 0x24, 0x33, 0x36, 0x76, 
0x3A, 0x33, 0x31, 0x0C, 0x0, OxOB, 0x1F, 0x7, 0x1E, 0x1A], 


[0x49, 0x65, 0x2D, 0x63, 0x76, 0x75, 0x6C, Ox6E, 0x76, 0x56, Ox5C, 
8, Ox4F, Ox4B, 0x47, 0x5D, 0x54, Ox5F, Ox1D, 0x26, Ox2C, 0x33, 
0x27, 0x28, Ox6F, 0x72, 0x75, 0x78, 0x7B, Ox7E, 0x41, 0x44], 


[0x45, 0x61, 0x31, 0x67, 0x72, 0x79, 0x68, 0x52, 0x4A, 0x52, 0x50, 
0x0C, Ox4B, 0x57, 0x43, 0x51, 0x58, 0x5B, 0x61, 0x37, 0x33, 0x2B, 
0x39, 0x39, 0x3C, 0x38, 0x79, Ox3A, 0x30, 0x17, 0x0B, 0x0C], 


[0x40, 0x64, 0x79, 0x75, Ox7F, Ox6F, 0x0, Ox4C, 0x40, 0x9, Ox4D, Ox5A, 
0x46, 0x5D, 0x57, 0x49, 0x57, Ox3B, 0x21, 0x23, 0x6A, 0x38, 0x23, 
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0x36, 0x24, Ox2A, Ox7C, Ox3A, Ox1A, 0x6, OxOD, OxOE, OxOA, 0x14, 
0x10], 


[0x72, 0x7C, 0x72, 0x79, 0x76, 0x0, 

0x50, 0x43, 0x4A, 0x59, Ox5D, 0x5B, 0x41, Ox41, 0x1B, 0x5A, 

0x24, 0x32, Ox2bE, 0x29, 0x28, 0x70, 0x20, 0x22, 0x38, 0x28, 0x36, 
0x0D, OxOB, 0x48, Ox4B, Ox4E]] 


def is string printable(s): 
return all(list(map(lambda x: curses.ascii.isprint(x), s))) 


cnt=1 
for msg in msgs: 
print ("message #%d" % cnt) 
for key in range(0, 256): 
result=[] 
tmp=key 
for i in msg: 
result.append (i^tmp) 


tmp=tmp+3 
if is string printable (result): 
print ("key=", key, "value=", "",join(list(map(chr,2 


G result)))) 
cnt=cnt+1 


Et nous obtenons: 


Listing 8.8 : Results 


message +1 

key= 20 value= 'eb^hs&s|""hudw| af{n-f%ljmSbnwlpk 
key= 21 value= ajc]i"}cawtgv{“bgto}g"millcmvkgh 
key= 22 value= bkd\j#rbbvsfuz!cduh|d#bhomdluj ni 
key= 23 value= check security device connection 
key= 24 value= Lifbl!pd|tqhsx#ejwjbb! ‘nQofbshlo 
message #2 

key= 7 value= No security device found 

key= 8 value= An#rbbvsVuz!cduhld#ghtme? !#!'!#! 
message #3 

key= 7 value= Bk<waoqNUpu$* yreoa\wpmpusj,bkIjh 
key= 8 value= Mj?vfnrO0jqv%*gxqd** vwlstlk/clHii 
key= 9 value= Lm»ugasLkvw&fgpgag^uvcrwml." mwhj 
key= 10 value= Ol!td'tMhwx'efwfbf!tubuvnm!anvok 
key= 11 value= No security device station found 
key= 12 value= In#rjbvsnuz! {duhdd#r{* whho#gPtme 
message #4 

key= 14 value= Number of authorized users exceeded 
key= 15 value= Ovlmdq!hg£ juknuhydk!vrbsp!Zy' dbefe 
message #5 

key= 17 value= check security device station 
key= 18 value= "ijbh!td' tmhwx'efwfbf ! tubuVnm! '! 
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Ici il y a un peu de déchet, mais nous pouvons rapidement trouver les messages en 
anglais. 


À propos, puisque l'algorithme est un simple chiffrement xor, la méme fonction peut 
étre utilisée pour chiffrer les messages. Si besoin, nous pouvons chiffrer nos propres 
messages, et patcher le programme en les insérant. 


8.8.3 Exemple +3: MS-DOS 


Un autre trés vieux logiciel pour MS-DOS de 1995, lui aussi développé par une société 
disparue depuis longtemps. 


Al’ ère pré-DOS extenders, presque tous les logiciels pour MS-DOS s'appuyaient sur 
sur des CPUs 8086 ou 80286, donc la code était massivement 16-bit. 


Le code 16-bit est presque le méme que celui déjà vu dans le livre, mais tous les 
registres sont 16-bit et il y a moins d'instructions disponibles. 


L'environnement MS-DOS n'avait pas de systéme de drivers, et n'importe quel pro- 
gramme pouvait s'adresser au matériel via les ports, donc vous pouvez voir ici les 
instructions OUT/IN, qui sont présentes dans la plupart des drivers de nos jours (il est 
impossible d'accéder directement aux ports en mode utilisateur sur tous les OSes 
modernes). 


Compte tenu de ceci, le programme MS-DOS qui fonctionne avec un dongle doit 
accéder le port imprimante LPT directement. 


Donc nous devons simplement chercher des telles instructions. Et oui, elles y sont: 


seg030:0034 out port proc far ; CODE XREF: sent pro-22p 
seg030:0034 ; sent pro+2Ap ... 
seg030:0034 

seg030:0034 arg 0 = byte ptr 6 

seg030:0034 

seg030:0034 55 push bp 

seg030:0035 8B EC mov bp, sp 

seg030:0037 8B 16 7E E7 mov dx, out port ; 0x378 
seg030:003B 8A 46 06 mov al, [bp+arg 0] 
seg030:003E EE out dx, al 

seg030:003F 5D pop bp 

seg030:0040 CB retf 

seg030:0040 out port endp 


(J'ai donné tous les noms de label dans cet exemple). 
out port() est référencé dans une seule fonction: 


seg030:0041 sent pro proc far ; CODE XREF: check dongle+34p 
seg030:0041 

seg030:0041 var 3 = byte ptr -3 

seg030:0041 var 2 - word ptr -2 

seg030:0041 arg 0 - dword ptr 6 

seg030:0041 

seg030:0041 C8 04 00 00 enter 4, 0 


seg030:0045 56 push si 
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seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 


:0046 
:0047 
:004B 
:004C 
:004E 
:0051 
:0054 
:0056 
:0059 
:005C 
:005E 
:005F 
:0062 
:0063 
:0066 
:0067 
:006A 
:006B 
:006E 
:006F 
:0071 
:0073 
:0073 
:0073 
:0074 
:0074 
:0074 
:0078 
:007A 
:007D 
:007E 
:0081 
:0082 
:0085 
:0086 
:0089 
:008A 
:008D 
:008E 
:0091 
:0092 
:0095 
:0096 
:0099 
:009A 
:009D 
:009E 
:00A1 
:00A2 
:00A5 
:00A6 
:00A9 
:00AA 


F6 
01 


FE 
F9 
C3 
B3 
C7 
AB 
D3 
A3 
C3 
9B 
C7 
93 
D3 
8B 


FF 


82 


FE 


04 


FD 


1F 


00 


FF 


00 


FF 


96 


00 


FF 


FF 


E7 


00 


push 
mov 
in 
mov 
and 
or 
mov 
mov 
and 
mov 
out 
push 
push 
call 
pop 
push 
push 
call 
pop 
xor 
jmp 


inc 


loc 359D4: ; 


di 

dx, in port 1 ; 0x37A 
al, dx 

bl, al 

bl, OFEh 

bl, 4 

al, bl 
[bp+var_3], al 
bl, 1Fh 

al, bl 

dx, al 

OFFh 

cs 

near ptr out_port 


cs 
near ptr out_port 
CX 

si, si 

short loc 359D4 


loc 359D3: ; CODE XREF: sent pro-37j 


S1 


CODE XREF: sent pro+30j 


si, 96h 

short loc_359D3 
0C3h 

cs 

near ptr out_port 


cs 

near ptr out_port 
cx 

0D3h 

cs 

near ptr out_port 
cx 

0C3h 

cs 

near ptr out_port 
cx 

OC7h 

cs 

near ptr out port 
CX 

0D3h 

cs 

near ptr out_port 
cx 

di, OFFFFh 
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seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 
seg030 


:00AD 
:00AF 
:00AF 
:00AF 
:00B2 
:00B2 
:00B2 
:00B4 
:00B8 
:00B9 
:00BB 
:00BD 
:00C0 
:00C0 
:00C0 
:00C5 
:00C7 
:00CA 
:00CC 
:00CC 
:00CC 
:00CF 
:00D0 
:00D3 
:00D4 
:00D7 
:00D7 
:00D7 
:00D8 
:00DB 
:00DC 
:00DF 
:00E0 
:00E3 
:00E4 
:00E7 
:00E9 
:00EC 
:00ED 
:00EF 
:00EF 
:00EF 
:00F2 
:00F5 
:00F8 
:00F9 
:00FC 
:00FE 
:0100 
:0103 
:0104 
:0107 
:0108 


EB 


BE 


40 


04 


00 


80 E7 


FE 08+ 


82 E7 


jmp 


loc 35A0F: ; 
mov 


loc 35A12: ; 
shl 
mov 
in 
test 
jnz 
or 


loc 35A20: ; 
test 
jz 
push 
jmp 


loc 35A2C: ; 
push 
push 
call 
pop 
push 


loc 35A37: ; 
push 
call 
pop 
push 
push 
call 
pop 
mov 
shl 
mov 
dec 
jnz 


loc 35A4F: ; 
les 
inc 
mov 
cbw 
mov 
or 
jnz 
push 
push 
call 
pop 
mov 


short loc 35A4F 


CODE XREF: sent pro+BDj 
si, 4 


CODE XREF: sent pro+ACj 
di, 1 
dx, in port 2 ; 0x379 
al, dx 
al, 80h 
short loc 35A20 
di, 1 


CODE XREF: sent pro+7Aj 
[bp+var_2], 8 
short loc 35A2C 
0D7h ; '+' 
short loc_35A37 


CODE XREF: sent pro+84j 
0C3h 
cs 
near ptr out port 
Cx 
OC7h 


CODE XREF: sent pro+89j 
cs 
near ptr out port 


cs 
near ptr out_port 


ax, [bp+var_2] 
ax, 1 
[bp+var_2], ax 
si 

short loc 35A12 


CODE XREF: sent pro+6Cj 
bx, [bp+arg 0] 
word ptr [bp+arg 0] 
al, es:[bx] 


[bp+var_2], ax 

ax, ax 

short loc_35A0F 

OFFh 

cs 

near ptr out_port 

cx 

dx, in port 1 ; 0x37A 
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seg030:010C EC in al, dx 

seg030:010D 8A C8 mov cl, al 

seg030:010F 80 E1 5F and cl, 5Fh 

seg030:0112 8A C1 mov al, cl 

seg030:0114 EE out dx, al 

seg030:0115 EC in al, dx 

seg030:0116 8A C8 mov cl, al 

seg030:0118 F6 C1 20 test cl, 20h 

seg030:011B 74 08 jz short loc 35A85 
seg030:011D 8A 5E FD mov bl, [bp+var_3] 
seg030:0120 80 E3 DF and bl, ODFh 
seg030:0123 EB 03 jmp short loc 35A88 
seg030:0125 

seg030:0125 loc 35A85: ; CODE XREF: sent pro+DA)j 
seg030:0125 8A 5E FD mov bl, [bp+var_3] 
seg030:0128 

seg030:0128 loc 35A88: ; CODE XREF: sent pro-E2j 
seg030:0128 F6 C1 80 test cl, 80h 

seg030:012B 74 03 jz short loc_35A90 
seg030:012D 80 E3 7F and bl, 7Fh 

seg030:0130 

seg030:0130 loc 35A90: ; CODE XREF: sent pro-EAj 
seg030:0130 8B 16 82 E7 mov dx, in port 1 ; 0x37A 
seg030:0134 8A C3 mov al, bl 

seg030:0136 EE out dx, al 

seg030:0137 8B C7 mov ax, di 

seg030:0139 5F pop di 

seg030:013A 5E pop si 

seg030:013B C9 leave 

seg030:013C CB retf 

seg030:013C sent pro endp 


Ceci est un «hashing » dongle Sentinel Pro, comme dans l'exemple précédent. C'est 
remarquable car des chaînes de texte sont passées ici, aussi, et des valeurs 16-bit 
sont renvoyées, puis comparées avec d'autres. 


Donc, voici comment le Sentinel Pro est accédé via les ports. 


L'adresse du port de sortie est en général 0x378, i.e., le port imprimante, oü les 
données pour les vieilles imprimantes de l'ére pré-USB étaient passées. 


Le port est uni-directionnel, car lorsqu'il a été développé, personne n'imaginait que 
quelqu'un aurait besoin de transférer de l'information depuis l'imprimante ??. 


Le seul moyen d'obtenir des informations de l'imprimante est le registre d'état sur 
le port 0x379, qui contient des bits tels que «paper out», «ack», «busy »—ainsi 
l'imprimante peut signaler si elle est préte ou non et si elle a du papier. 


Donc, le dongle renvoie de l'information dans l'un de ces bits, un bit à chaque itéra- 
tion. 


1?Si nous considérons seulement Centronics. Le standard IEEE 1284 suivant permet le transfert d'infor- 
mation depuis l'imprimante. 
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in port 2 contient l'adresse du mot d'état (0x379) et in port 1 contient le re- 
gistre de contróle d'adresse (0x37A). 


Il semble que le dongle renvoie de l'information via le flag «busy » en seg030 : 00B9 : 
chaque bit est stocké dans le registre DI, qui est renvoyé à la fin de la fonction. 


Que signifie tous ces octets envoyés sur le port de sortie? Difficile à dire. Peut-étre 
des commandes pour le dongle. 


Mais d'une maniére générale, il n'est pas nécessaire de savoir: il est facile de ré- 
soudre notre táche sans le savoir. 


Voici la routine de vérification du dongle: 


00000000 struct 0 struc ; (sizeof=0x1B) 

00000000 field 0 db 25 dup(?) ; string(C) 

00000019 A dw ? 

0000001B struct 0 ends 

dseg:3CBC 61 63 72 75* Q struct 0 <'hello', 01122h> 

dseg:3CBC 6E 00 00 00+ ; DATA XREF: check dongle+2Eo 
. Skipped ... 

dseg:3E00 63 6F 66 66+ struct 0 «'coffee', 7EB7h> 

dseg:3E1B 64 6F 67 00+ struct 0 «'dog', OFFADh» 

dseg:3E36 63 61 74 00+ struct_0 «'cat', OFF5Fh» 

dseg:3E51 70 61 70 65+ struct 0 «'paper', OFFDFh» 

dseg:3E6C 63 6F 6B 65+ struct O0 «'coke', OF568h» 

dseg:3E87 63 6C 6F 63+ struct 0 «'clock', 55EAh> 

dseg:3EA2 64 69 72 00+ struct 0 «'dir', OFFAEh> 

dseg:3EBD 63 6F 70 79+ struct_0 «'copy', 0F557h» 

seg030:0145 check dongle proc far ; CODE XREF: sub 3771D+3EP 

seg030:0145 

seg030:0145 var 6 = dword ptr -6 

seg030:0145 var 2 = word ptr -2 

seg030:0145 

seg030:0145 C8 06 00 00 enter 6, 0 

seg030:0149 56 push si 

seg030:014A 66 6A 00 push large 0 ; newtime 

seg030:014D 6A 00 push 0 ; cmd 

seg030:014F 9A C1 18 00+ call  biostime 

seg030:0154 52 push dx 

seg030:0155 50 push ax 

seg030:0156 66 58 pop eax 

seg030:0158 83 C4 06 add sp, 6 

seg030:015B 66 89 46 FA mov [bp+var 6], eax 

seg030:015F 66 3B 06 D8+ cmp eax, expiration 

seg030:0164 7E 44 jte short loc 35B0A 

seg030:0166 6A 14 push 14h 

seg030:0168 90 nop 

seg030:0169 OE push CS 


seg030:016A E8 52 00 call near ptr get rand 
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seg030:016D 59 pop Cx 

seg030:016E 8B FO mov si, ax 
seg030:0170 6B CO 1B imul ax, 1Bh 
seg030:0173 05 BC 3C add ax, offset Q 
seg030:0176 1E push ds 

seg030:0177 50 push ax 

seg030:0178 OE push cs 

seg030:0179 E8 C5 FE call near ptr sent pro 
seg030:017C 83 C4 04 add sp, 4 
seg030:017F 89 46 FE mov [bp+var_2], ax 
seg030:0182 8B C6 mov ax, si 
seg030:0184 6B CO 12 imul ax, 18 
seg030:0187 66 OF BF CO movsx eax, ax 
seg030:018B 66 8B 56 FA mov edx, [bp+var 6] 
seg030:018F 66 03 DO add edx, eax 
seg030:0192 66 89 16 D8+ mov expiration, edx 
seg030:0197 8B DE mov bx, si 
seg030:0199 6B DB 1B imul bx, 27 
seg030:019C 8B 87 D5 3C mov ax, _Q. A[bx] 
seg030:01A0 3B 46 FE cmp ax, [bp+var_2] 
seg030:01A3 74 05 jz short loc_35B0A 
seg030:01A5 B8 01 00 mov ax, 1 
seg030:01A8 EB 02 jmp short loc 35B0C 
seg030:01AA 

seg030:01AA loc 35B0A: ; CODE XREF: check _dongle+1Fj 
seg030:01AA ; check dongle+5Ej 
seg030:01AA 33 CO xor ax, ax 
seg030:01AC 

seg030:01AC loc 35B0C: ; CODE XREF: check dongle-63j 
seg030:01AC 5E pop si 

seg030:01AD C9 leave 

seg030:01AE CB retf 

seg030:01AE check_dongle endp 


Puisque la routine peut étre appelée trés fréquemment, e.g., avant l'exécution de 
chaque fonctionnalité importante du logiciel, et accéder au ongle est en général lent 
(à cause du port de l'imprimante et aussi du MCU lent du dongle), ils ont probable- 
ment ajouté un moyen d'éviter le test du dongle, en vérifiant l'heure courante dans 
la fonction biostime(). 


La fonction get rand() utilise la fonction C standard: 


seg030:01BF get rand proc far ; CODE XREF: check dongle+25p 
seg030:01BF 

seg030:01BF arg_0 = word ptr 6 
seg030:01BF 

seg030:01BF 55 push bp 

seg030:01C0 8B EC mov bp, sp 
seg030:01C2 9A 3D 21 00+ call rand 
seg030:01C7 66 OF BF CO movsx eax, ax 
seg030:01CB 66 OF BF 56+ movsx edx, [bp+arg 0] 
seg030:01D0 66 OF AF C2 imul eax, edx 
seg030:01D4 66 BB 00 80+ mov ebx, 8000h 


seg030:01DA 66 99 cdq 
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seg030:01DC 66 F7 FB idiv ebx 
seg030:01DF 5D pop bp 
seg030:01E0 CB retf 
seg030:01E0 get rand endp 


Donc la chaíne de texte est choisi au hasard, passé au dongle, et ensuite le résultat 
du hachage est comparé à la valeur correcte. 


Les chaines de texte semblent étre construites aléatoirement aussi, lors du dévelop- 
pement du logiciel. 


Et voici comment la fonction principale de vérification du dongle est appelée: 


seg033:087B 9A 45 01 96+ call check dongle 


seg033:0880 0B CO or ax, ax 

seg033:0882 74 62 jz short OK 

seg033:0884 83 3E 60 42+ cmp word 620E0, 0 

seg033:0889 75 5B jnz short OK 

seg033:088B FF 06 60 42 inc word 620E0 

seg033:088F 1E push ds 

seg033:0890 68 22 44 push offset aTrupcRequiresA ; 
"This Software Requires a Software Lock\n" 

seg033:0893 1E push ds 

seg033:0894 68 60 E9 push offset byte 6C7EO0 ; dest 

seg033:0897 9A 79 65 00+ call _strcpy 

seg033:089C 83 C4 08 add sp, 8 

seg033:089F 1E push ds 

seg033:08A0 68 42 44 push offset aPleaseContactA ; "Please Contact 

seg033:08A3 1E push ds 

seg033:08A4 68 60 E9 push offset byte 6C7EO0 ; dest 

seg033:08A7 9A CD 64 00+ call _strcat 


Il est facile de contourner le dongle, il suffit de forcer la fonction check dongle() à 
renvoyer toujours 0. 


Par exemple, en insérant du code à son début: 


mov ax,0 
retf 


Le lecteur attentif peut se rappeler que la fonction C strcpy() prend en général 
deux pointeurs dans ses arguments, mais nous voyons que 4 valeurs sont passées: 


seg033:088F 1E push ds 

seg033:0890 68 22 44 push offset aTrupcRequiresA ; 
"This Software Requires a Software Lock\n" 

seg033:0893 1E push ds 

seg033:0894 68 60 E9 push offset byte 6C7E0 ; dest 

seg033:0897 9A 79 65 00+ call _strcpy 

seg033:089C 83 C4 08 add sp, 8 


Ceci est relatif au modéle de mémoire de MS-DOS. Vous pouvez en lire plus à ce 
sujet ici: 11.7 on page 1297. 
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Donc, comme vous pouvez le voir, strcpy() et toute autre fonction qui prend un/des 
pointeur(s) en argument travaille avec des paires 16-bit. 


Retournons a notre exemple. DS est actuellement l'adresse du segment de données 
dans l'exécutable, où la chaîne de texte est stockée. 


Dans la fonction sent pro(), chaque octet de la chaine est chargé en 
seg030:00EF : l'instruction LES charge simultanément la paire ES:BX depuis l'argu- 
ment transmis. 


Le MOV en seg030:00F5 charge l'octet depuis la mémoire sur laquelle pointe la paire 
ES:BX. 


8.9 Cas de base de données chiffrée #1 


(Cette partie est apparue initialement dans mon blog le 26 aoüt 2015. Discussion: 
https://news.ycombinator.com/item?id-10128684.) 


8.9.1 Base64 et entropie 


J'ai un fichier XML contenant des données chiffrées. Peut-étre est-ce relatif à des 
commandes et/ou des information clients. 


<?xml version = "1.0" encoding = "UTF-8"?> 
«Orders» 
«Order» 
<OrderID>1</OrderID> 
«Data»yjmxhXUbhB/5MV45chPsXZWAJwIh1SO0aD9lFn3XuJMSxJ3/E* 7 
& UE3hsnH</Data> 
</Order> 
«Order» 
<OrderID>2</OrderID> 
<Data>0KGe/wnypFBjsy+U0C2P9 f C5nDZP3XDZLMPCRaiBw90j IK6TUSU ? 
S =</Data> 
«/Order» 
«Order» 
<OrderID>3</OrderID> 
<Data>mqkXfdzvQKvEArdzh+zD9oETVGBFvcTBLs2ph1b5bYddExzp</ 7 
y Data» 
</Order> 
«Order» 
«OrderID»4«/OrderID» 
<Data>FCx6JhIDqnESyT3HAepyE1BJ3cJd7wCk+APCRUeuNt ZdpCvQ2MR/7 7 
kLXt f UHuA==</Data> 
</Order> 


"n 


Le fichier est disponible ici. 


Ce sont clairement des données encodées en base64, car toutes les chaînes consistent 
en des caractéres Latin, chiffres, plus (+) et symbole slash (/). Il peut y avoir 1 ou 2 
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symboles de remplissage (=), mais ils ne se trouvent jamais au milieu d'une chaine. 
Gardez à l'esprit ces propriétés du base64, il est trés facile de les reconnaitre. 


Décodons les et calculons l'entropie (9.2 on page 1225) de ces blocs dans Wolfram 
Mathematica: 


In[]:= ListOfBase64Strings = 


Map[First[#[[3]]] €, Cases[Import["encrypted.xml"], XMLElement["Data", _,/ 
G  ], Infinity]]; 


In[]:= BinaryStrings = 
Map[ImportString[#, {"Base64", "String"}] €, ListOfBase64Strings]; 


In[]:= Entropies = Map[N[Entropy[2, #]] &, BinaryStrings]; 
In[]:= Variance[Entropies ] 
Out[]= 0.0238614 


La variance est basse. Cela signifie que l'entropie des valeurs ne sont pas tres diffé- 
rentes les unes des autres. Ceci est visible sur le graphique: 


In[]:= ListPlot[Entropies ] 
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La plupart des valeurs sont entre 5.0 et 5.4. Ceci est un signe que les données sont 
compressées et/ou chiffrées 


Pour comprendre la variance, calculons l'entropie de toutes les liens du livre de Co- 
nan Doyle The Hound of the Baskervilles : 
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In[]:= BaskervillesLines = Import["http://ww.gutenberg.org/cache/epub 7 
S /2852/pg2852.txt", "List"]; 


In[]:= EntropiesT = Map[N[Entropy[2, #]] €, BaskervillesLines]; 


In[]: 
Out[] 


Variance[EntropiesT] 
2.73883 


In[]:= ListPlot[EntropiesT] 
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La plupart des valeurs sont regroupées autour de 4, mais il y a aussi des valeurs qui 
sont plus petites, et elles influencent la valeur finale de la variance. 


Peut-être que les chaînes courtes ont une entropie plus petite, prenons les chaînes 
courtes du livre de Conan Doyle. 


In[]:= Entropy[2, "Yes, sir."] // N 
Out[]= 2.9477 


Essayons encore plus petit: 


In[]:= Entropy[2, "Yes"] // N 
Out[]= 1.58496 
In[]: 


Entropy[2, "No"] // N 
Out[]= 1. 
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8.9.2 Est-ce que les données sont compressées? 


OK, donc nos données sont compressées et/ou chiffrées. Sont-elles compressées? 
Presque tous les compresseurs de données ajoutent un entéte au début, une signa- 
ture ou quelque chose comme ca. Comme on peut le voir, il n'y a pas de motifs 
communs au début de chaque bloc. Il est toujours possible qu'il s'agisse d'un com- 
presseur de données écrit à la main, mais c'est trés rare. D'un autre cóté, les al- 
gorithmes de chiffrement maison sont plus répandus, car il est facile d'en faire un. 

Même des systèmes de chiffrement sans clef primitifs comme memfrob()?? et ROT13 
fonctionnent bien sans erreur. C'est un gros défi d'écrire un compresseur depuis zé- 
ro, en utilisant seulement sa fantaisie et son imagination de facon à ce qu'il n'ait 
pas de bugs évidents. Certains programmeurs implémentent des fonctions de com- 
pression de données en lisant des livres, mais ceci est aussi rare. Les deux moyens 
les plus fréquents sont: 1) utiliser simplement la bibliothéque open-source zlib; 2) 
copier/coller quelque chose de quelque part. Les algorithmes de compression open- 
source mettent en général une sorte d'en-téte, ainsi que les algorithmes de sites 
comme http://www. codeproject.com/. 


8.9.3 Est-ce que les données sont chiffrées? 


Les algorithmes majeurs de chiffrement de données traitent les données par bloc. 
DES—8 octets, AES—16 octets. Si le buffer en entrée n'est pas divisible par la taille 
du bloc, des zéros sont ajoutés (ou quelque chose d'autre), afin que les donnés 
chiffrées soient alignées sur la taille du bloc de l'algorithme. Ce n'est pas notre cas. 


En utilisant Wolfram Mathematica, j'ai analysé la longueur des blocs: 


In[]:= Counts[Map[StringLength[#] €, BinaryStrings]] 

Out[]= «|42 -> 1858, 38 -> 1235, 36 -> 699, 46 -> 1151, 40 -> 1784, 
44 -> 1558, 50 -> 366, 34 -> 291, 32 -» 74, 56 -» 15, 48 -> 716, 
30 -> 13, 52 -» 156, 54 -> 71, 60 -> 3, 58 -> 6, 28 -» 4|» 


1858 blocs ont une taille de 42 octets, 1235 blocs ont une taille de 38 octets, etc. 
J'ai fait un graphe: 


ListPlot[Counts[Map[StringLength[#] €, BinaryStrings]]] 


20http://linux.die.net/man/3/memf rob 
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Donc, la plupart des blocs ont une taille entre ~36 et —48. Il y a un autre chose à 
remarquer: tous les blocs ont une taille paire. Pas un bloc n'a une taille impaire. 


Il y a, toutefois, des flux de chiffrement qui opérent au niveau de l'octet ou méme 
du bit. 


8.9.4 CryptoPP 


Le programme qui peut parcourir cette base de données chiffrées est écrit en CH et 
le code .NET est fortement obscurci. Néanmoins, il y a une DLL avec du code x86, qui, 
aprés un bref examen, contient des parties de la bibliothéque open-source connue 
CryptoPP! (J'ai juste repéré des chaînes «CryptoPP » dedans.) Maintenant, c'est trés 
facile de trouver toutes les fonctions à l'intérieur de la DLL car la bibliothéque Cryp- 
toPP est open-source. 


La bibliothéque CryptoPP contient beaucoup de fonctions de chiffrement, AES in- 
clus (AKA Rijndael). Les CPUs x86 récents possédent des instructions dédiées à AES 
comme AESENC, AESDEC et AESKEYGENASSIST?!. Elles ne font pas le chiffrement/dé- 
chiffrement complétement, mais elles font une part significative du travail. Et les 
nouvelles versions de CryptoPP les utilisent. Par exemple, ici: 1, 2. À ma surprise, 
lors du déchiffrement, AESENC est exécutée, tandis que AESDEC ne l'est pas (j'ai vé- 
rifié avec mon utilitaire tracer, mais n'importe quel débogueur peut étre utilisé). J'ai 
vérifié, si mon CPU supporte réellement les instructions AES. Certains CPUs Intel i3 
ne les supportent pas. Et si non, la bibliothéque CryptoPP se rabat sur les fonctions 


2lhttps://en.wikipedia.org/wiki/AES instruction set 
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implémentées de l'ancienne facon ^^. Mais mon CPU les supporte. Pourquoi AESDEC 
n'est pas exécuté? Pourquoi le programme utilise le chiffrement AES pour déchiffrer 
la base de données? 


OK, ce n'est pas un probléme de trouver la fonction qui chiffre les blocs. Elle est 
appelée 

CryptoPP::Rijndael::Enc::ProcessAndXorBlock : src, et elle peut être appelée depuis 
une autre fonction: 

Rijndael::Enc::AdvancedProcessBlocks() src, qui, à son tour, appelle les deux fonc- 
tions: ( AESNI Enc Block et AESNI Enc 4 Blocks ) qui ont les instructions AESENC. 


Donc, a en juger par les entrailles de CryptoPP 
CryptoPP::Rijndael::Enc::ProcessAndXorBlock() chiffre un bloc 16-octet. Mettons un 
point d'arrét dessus et voyons ce qui se produit pendant le déchiffrement. J'utilise à 
nouveau mon petit outil tracer. Le logiciel doit déchiffrer le premier bloc de données 
maintenant. Oh, à propos, voici le premier bloc de données converti de l'encodage 
en base64 vers des données hexadécimale, faisons le manuellement: 


00000000: CA 39 B1 85 75 1B 84 1F F9 31 5E 39 72 13 EC 5D .9..u....1^9r7 


Los 

00000010: 95 80 27 02 21 D5 2D 1A OF D9 45 OF 75 EE 24 C4 ..'.l.-...E.u.$7 
Go. 

00000020: B1 27 7F 84 FE 41 37 86 C9 CO a pas os 


Voici les arguments de la fonction d'aprés les fichiers sources de CryptoPP: 


size t Rijndael::Enc::AdvancedProcessBlocks(const byte *inBlocks, const 2 
y byte *xorBlocks, byte *outBlocks, size t length, word32 flags); 


Donc, il y a 5 arguments. Les flags possibles sont: 


enum (BT InBlockIsCounter-1, BT DontIncrementInOutPointers-2, BT XorInput 
Y =4, BT_ReverseDirection=8, BT AllowParallel-16) 7 
y FlagsForAdvancedProcessBlocks; 


OK, lancons tracer sur la fonction ProcessAndXorBlock() : 


. tracer.exe -l:filename.exe bpf-filename.exe!0x4339a0,args:5,dump args:07 
V x10 


Warning: no tracer.cfg file. 

PID-1984|New process software.exe 

no module registered with image base 0x77320000 

no module registered with image base 0x76e20000 

no module registered with image base 0x77320000 

no module registered with image base 0x77220000 

Warning: unknown (to us) INT3 breakpoint at ntdll.dll!^ 
s LdrVerifyImageMatchesChecksum+0x96c (0x776c103b) 

(0) software.exe!0x4339a0(0x38b920, 0x0, 0x38b978, 0x10, 0x0) (called from ^ 
V software.exe!.text+0x33c0d (0x13e4c0d)) 

Argument 1/5 


22https://github.com/mmoss/cryptopp/blob/2772f7b57182b31a41659b48d5f35a7b6cedd34d/src/ 
rijndael.cpp#L355 


0038B920: 01 00 00 00 FF FF FF FF-79 C1 69 OB 67 C1 04 7D "........ y.i.g7 
e ee ais 

Argument 3/5 

0038B978: CD CD CD CD CD CD CD CD-CD CD CD CD CD CD CD CD v 
CORNE Ais NE 

(0) software.exe!0x4339a0() -> 0x0 

Argument 3/5 difference 

00000000: C7 39 4E 7B 33 1B D6 1F-B8 31 10 39 39 13 A5 5D ".9N2 
& (3....1.99..]" 

(0) software.exe!0x433920(0x38a828, 0x38a838, 0x38bb40, 0x0, 0x8) (called 2 
V. from software.exe!.text+0x3a407 (0x13eb407)) 

Argument 1/5 

0038A828: 95 80 27 02 21 D5 2D 1A-OF D9 45 OF 75 EE 24 C4 "..'.!.-...E.u.$, 
(es ou 

Argument 2/5 

0038A838: B1 27 7F 84 FE 41 37 86-C9 CO 00 CD CD CD CD CD ".'...A77 


Argument 3/5 

0038BB40: CD CD CD CD CD CD CD CD-CD CD CD CD CD CD CD CD v 
Mo babe cala aite a 7 

(0) software. exe! 0x4339a0() -> 0x0 

(0) software. exe! 0x4339a0(0x38b920, 0x38a828, 0x38bb30, 0x10, 0x0) (called 2 
y from software.exe!.text+0x33c0d (0x13e4c0d)) 

Argument 1/5 

0038B920: CA 39 B1 85 75 1B 84 1F-F9 31 5E 39 72 13 EC 5D ".9..u....1^9r7 
g "S 

Argument 2/5 

0038A828: 95 80 27 02 21 D5 2D 1A-OF D9 45 9F 75 EE 24 C4 "..'.!.-...E.u.$, 
oM 

Argument 3/5 

0038BB30: CD CD CD CD CD CD CD CD-CD CD CD CD CD CD CD CD v 
TARDE e EARS " 

(0) software.exe!0x4339a0() -» 0x0 

Argument 3/5 difference 

00000000: 45 00 20 00 4A 00 4F 00-48 00 4E 00 53 00 00 00 "E. .J.0.H.N.S7 
CENE 

(0) software.exe!0x4339a0(0x38b920, 0x0, 0x38b978, 0x10, 0x0) (called from 2 
S software.exe!.text+0x33c0d (0x13e4c0d)) 

Argument 1/5 


0038B920: 95 80 27 02 21 D5 2D 1A-0F D9 45 9F 75 EE 24 C4 "..'.!.-...E.u.$2 
G : LL 

Argument 3/5 

0038B978: 95 80 27 02 21 D5 2D 1A-0F D9 45 OF 75 EE 24 C4 "..'.!.-...E.u.$2 
Es LL 


(0) software.exe!0x4339a0() -> 0x0 

Argument 3/5 difference 

00000000: B1 27 7F E4 9F 01 E3 81-CF C6 12 FB B9 7C F1 BC 2 
Noe run O eec | 

PID-1984|Process software.exe exited. ExitCode-0 (0x0) 


Ici nous pouvons voir l'entrée de la fonction ProcessAndXorBlock(), et sa sortie. 
Ceci est la sortie de la fonction lors du premier appel: 
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00000000: C7 39 4E 7B 33 1B D6 1F-B8 31 10 39 39 13 A5 5D ".9N2 
Y (3....1.99..]" 


Puis la fonction ProcessAndXorBlock() est appelée avec un bloc de longueur zéro, 
mais avec le flag 8 (BT ReverseDirection). 


Second appel: 


00000000: 45 00 20 00 4A 00 4F 00-48 00 4E 00 53 00 00 00 "E. .J.0.H.N.S7 
Guara” 


Maintenant, il y a des chaines qui nous sont familiéres! 
Troisiéme appel: 


00000000: B1 27 7F E4 9F 01 E3 81-CF C6 12 FB B9 7C F1 BC 7 
HAN |.." 


La premiére sortie est trés similaire aux 16 premiers octets du buffer chiffré. 


Sortie du premier appel à ProcessAnaXorBlock() : 


00000000: C7 39 4E 7B 33 1B D6 1F-B8 31 10 39 39 13 A5 5D ".9N2 
S (3....1.99..]" 


16 premiers octets du buffer chiffré: 


00000000: CA 39 B1 85 75 1B 84 1F F9 31 5E 39 72 13 EC 5D  .9..u....1^9r..] 


Il y a trop d'octets égaux! Comment le résultat du chiffrement AES peut-il étre aus- 
si similaire au buffer chiffré alors que ceci n'est pas du chiffrement mais bien du 
déchiffrement?! 


8.9.5 Mode Cipher Feedback 


La réponse est CFB?? : Dans ce mode, l'algorithme AES n'est pas utilisé comme 
un algorithme de chiffrement, mais comme un dispositif qui génére des données 
aléatoires cryptographiquement sûres. Le chiffrement effectif est obtenu en utilisant 
une simple opération XOR. 


Voici l'algorithme de chiffrement (les images proviennent de Wikipédia) : 


23Cipher Feedback 
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Initialization Vector (IV) 


OT] 
K block cipher K block cipher K block cipher 
ey encryption ey encryption ey encryption 
Plaintext Plaintext Plaintext 
[IIIIIIIIITIT]- - CIIIIIIIIIIIT]- - [IIIIIIIIIIIT]- - l 
OTITITIITITIIT] CONN CONN 


Ciphertext Ciphertext Ciphertext 


Cipher Feedback (CFB) mode encryption 


Et le déchiffrement: 


Initialization Vector (IV) 


COIN] 


| 


Ke block cipher K block cipher K block cipher 
y encryption 7 encryption EY encryption 


$ Ciphertext $ Ciphertext $ Ciphertext 
<O -<N <O 
O O CLITITIIIIIIITI 

Plaintext Plaintext Plaintext 


Cipher Feedback (CFB) mode decryption 


Maintenant regardons: le chiffrement AES génére 16 octets (ou 128 bits) de données 
aléatoires destinées à étre utilisées lors du XOR, qui nous oblige à utiliser tous les 
16 octets? Si à la derniére itération nous n'avons qu'un octet de données, nous ne 
chiffrons qu'un octet avec un octet de données aléatoires générée. Ceci conduit à 
une propriété importante du mode CFB : les données ne doivent pas étre adaptées 
à une taille, des données de taille arbitraire peuvent étre chiffrées et déchiffrées. 


Oh, c'est pour ca que les blocs chiffrés ne sont pas complétés. Et c'est pourquoi 
l'instruction AESDEC n'est jamais appelée. 


Essayons de déchiffrer le premier bloc manuellement, en utilisant Python. Le mode 
CFB utilise aussi un IV, comme semence pour CSPRNG^^. Dans notre cas, l'IV est le 
bloc qui est chiffré à la premiére itération: 


24Cryptographically Secure Pseudorandom Number Generator (générateur de nombres pseudo- 
aléatoire cryptographiquement súr) 


0038B920: 01 00 00 00 FF FF FF FF-79 C1 69 0B 67 C1 04 7D "........ y.i.gv 
G m 


Oh, et nous devons aussi retrouver la clef de chiffrement. Il y a AESKEYGENASSIST 
dans la DLL, et elle est appelée, et elle est utilisée dans la fonction 
src. C'est facile de la trouver dans IDA et de mettre un point d'arrét. Voyons: 


. tracer.exe -l:filename.exe bpf-filename.exe!0x435c30,args:3,dump args:07 
y x10 


Warning: no tracer.cfg file. 

PID-2068|New process software.exe 

no module registered with image base 0x77320000 

no module registered with image base 0x76e20000 

no module registered with image base 0x77320000 

no module registered with image base 0x77220000 

Warning: unknown (to us) INT3 breakpoint at ntdll.dll!^ 
y LdrVerifyImageMatchesChecksum+0x96c (0x776c103b) 

(0) software.exe!0x435c30(0x15e8000, 0x10, 0x14f808) (called from software.” 
y exel.text-0x22fal (0x13d3fal)) 

Argument 1/3 

015E8000: CD C5 7E AD 28 5F 6D El-CE 8F CC 29 B1 21 88 8E "..-.( m....)7 
2 

Argument 3/3 

0014F808: 38 82 58 01 C8 B9 46 00-01 D1 3C 01 00 F8 14 00 "8.X...F7 
-— Ses a aie B 

Argument 3/3 +0x0: software.exe!.rdata+0x5238 

Argument 3/3 +0x8: software.exe!.text+0x1c101 

(0) software.exe!0x435c30() -» 0x13c2801 

PID-2068|Process software.exe exited. ExitCode-0 (0x0) 


Donc, ceci est la clef: CD C5 7E AD 28 5F 6D E1-CE 8F CC 29 B121 88 8E. 


Durant le déchiffrement manuel, nous obtenons ceci: 


00000000: OD 00 FF FE 46 00 52 00 41 00 4E 00 4B 00 49 00  ....F.R.A.N.K.I7 
Ve. 

00000010: 45 00 20 00 4A 00 4F 00 48 00 4E 00 53 00 66 66 E. .J.O.H.N.S.2 
& ff 

00000020: 66 66 66 9E 61 40 D4 07 06 01 fff.a@.... 


Maintenant, c'est quelque chose de lisible! Et nous comprenons pourquoi il y avait 
autant d'octets égaux dans la première itération de déchiffrement: car le text en 
clair a beaucoup d'octet a zéro! Déchiffrons le second bloc: 


00000000: 17 98 DO 84 3A E9 72 4F DB 82 3F AD E9 3E 2A A8 ....:.r07 
S. suf ust 
00000010: 41 00 52 00 52 00 4F 00 4E 00 CD CC CC CC CC CC A.R.R.O.NY 


y 
00000020: 1B 40 D4 07 06 01 .@.... 


Les troisième, quatrième et cinquième: 


00000000: 5D 90 59 06 EF F4 96 B4 7C 33 A7 4A BE FF 66 AB ].Y..... 13.J..f2 
Go. 

00000010: 49 00 47 00 47 00 53 00 00 00 00 00 00 CO 65 40 1.G.G.S....... 2 
y ea 


00000020: D4 07 06 01 


00000000: D3 15 34 5D 21 18 7C 6E AA F8 2D FE 38 F9 D7 4E ..4]!.|n..-.8..% 
GN 
00000010: 41 00 20 00 44 00 4F 00 48 00 45 00 52 00 54 00 A. .D.O.H.E.R.T2 


Go. 
00000020: 59 00 48 El 7A 14 AE FF 68 40 D4 07 06 02 Y.H.z...hQ.... 
00000000: 1E 8B 90 0A 17 7B C5 52 31 6C 4E 2F DE 1B 27 19 ..... (.R1lNZ 
G x i 


00000010: 41 00 52 00 43 00 55 00 53 00 00 00 00 00 00 60 A.R.C.U.S7 


E 
00000020: 66 40 D4 07 06 03 f@.... 


Tous les blocs déchiffrés semblent correct, à l'exception des 16 premiers octets. 


8.9.6 Initializing Vector 


Qu'est-ce qui peut affecter les 16 premiers octets? 
Revenons à nouveau à l'algorithme de déchiffrement CFB : 8.9.5 on page 1120. 


Nous pouvons voir que l'IV peut affecter le déchiffrement de la première opération 
de déchiffrement, mais pas la seconde, car lors de la seconde itération, le texte 
chiffré de la premiére itération est utilisé, et en cas de déchiffrement, c'est le méme, 
quelque soit l'IV! 


Donc, l'IV est sans doute différent à chaque fois. En utilisant mon tracer, j'ai regardé 
la premiére entrée lors du déchiffrement du second bloc du fichier XML : 


0038B920: 02 00 00 00 FE FF FF FF-79 C1 69 OB 67 C1 04 7D "........ y.i.gv 
As : P ou 

...troisiéme: 

0038B920: 03 00 00 00 FD FF FF FF-79 C1 69 OB 67 C1 04 7D "........ y.i.gv 
S . +" 


Il semble que le premier et le cinquième octet changent à chaque fois. J'en ai finale- 
ment conclu que le premier entier 32-bit est simplement OrderlD du fichier XML, et le 
second entier 32-bit est aussi OrderlD, mais multiplié par -1. Tous les 8 autres octets 
sont les mémes pour chaque opération. Maintenant, j'ai déchiffré la base de données 
entière: https://beginners. re/paywall/RE4B- source/current-tree//examples/ 
encrypted DBl/decrypted.full.txt. 


Le script Python utilisé pour ceci est: https: //beginners.re/paywall/RE4B- source/ 
current-tree//examples/encrypted DBl/decrypt blocks.py. 
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Peut-étre que l'auteur voulait chiffrer chaque bloc différemment, donc il a utilisé 
OrderlD comme une partie de la clef. ll aurait aussi été possible de créer une clef 
AES différente, au lieu de l'IV. 


Dinc maintenant nous savons que l'IV affecte seulement le premier bloc lors du 
déchiffrement en mode CFB, ceci en est une caractéristique. Tous les autres blocs 
peuvent être déchiffrés sans connaître l'IV, mais en utilisant la clef. 


OK, donc pourquoi le mode CFB ? Apparemment, parce que le tout premier exemple 

sur le wiki de CryptoPP utilise le mode CFB : http://www.cryptopp.com/wiki/Advanced 
Encryption Standard*Encrypting and Decrypting Using AES.On peut aussi sup- 
poser que le développeur l'a choisi pour sa simplicité: l'exemple peut chiffrer/déchif- 

frer des chaînes de texte de longueur arbitraire, sans remplissage. 


Il est aussi probable que l'auteur du programme a juste copié/collé l'exemple depuis 
la page wiki de CryptoPP. Beaucoup de programmeurs font ca. 


La seule différence est que l'IV est choisi aléatoirement dans l'exemple du wiki de 
CryptoPP, alors que cet indéterminisme n'était pas permis aux programmeurs du lo- 
giciel que nous disséquons maintenant, donc ils ont choisi d'initialiser l'IV en utilisant 
OrderlD. 


Nous pouvons maintenant procéder à l'analyse du cas de chaque octet dans le bloc 
déchiffré. 


8.9.7 Structure du buffer 


Prenons les quatre premier bloc déchiffrés: 


00000000: OD 00 FF FE 46 00 52 00 41 00 4E 00 4B 00 49 00  ....F.R.A.N.K.I7 
meres 45 00 20 00 4A 00 4F 00 48 00 4E 00 53 00 66 66 E. .J.0.H.N.S.7 
meno 66 66 66 9E 61 40 D4 07 06 01 fff.a@.... 
00000000: OB 00 FF FE 4C 00 4F 00 52 00 49 00 20 00 42 00  ....L.O.R.I. .B7 
oie 41 00 52 00 52 00 4F 00 4E 00 CD CC CC CC CC CC A.R.R.0.N2 
00000020: 18 40 DA 07 06 01 fae 
00000000: 0A 00 FF FE 47 00 41 00 52 00 59 00 20 00 42 00 ....G.A.R.Y. .B7 
mer 49 00 47 00 47 00 53 00 00 00 00 00 00 CO 65 40 I.G.G.S....... ZL 
sateen. D4 07 06 O1 
00000000: OF 00 FF FE 4D 00 45 00 4C 00 49 00 4E 00 44 00  ....M.E.L.I.N.D7 
de 41 00 20 00 44 00 4F 00 48 00 45 00 52 00 54 00 A. .D.O.H.E.R.T2 
x 


00000020: 59 00 48 El 7A 14 AE FF 68 40 D4 07 06 02 Y.H.z...hQ.... 
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On voit clairement des chaínes de textes encodées en UTF-16, ce sont les noms et 
noms de famille. Le premier octet (ou mot de 16-bit) semble étre la longueur de la 
chaíne, nous pouvons vérifier visuellement. FF FE semble étre le BOM Unicode. 


Il y a 12 autres octets aprés chaque chaine. 


En utilisant ce script (https://beginners.re/paywall/REA4B- source/current-tree/ 
/examples/encrypted DB1/dump buffer rest.py) j'ai obtenu une sélection aléa- 
toire de fins (de bloc) : 


dennis@...:$ python decrypt.py encrypted.xml | shuf | head -20 

00000000: 48 El 7A 14 AE 5F 62 40 DD 07 05 08 H.z.. bQ.... 
00000000: 00 00 00 00 00 40 5A 40 DC 07 08 18 | |  ..... @Z@.... 
00000000: 00 00 00 00 00 80 56 40 D7 07 OB 04 ee V@.... 
00000000: 00 00 00 00 00 60 61 40 D7 07 OC 1C | | . ...... a@.... 
00000000: 00 00 00 00 00 20 63 40 D9 07 05 18 | |  ..... c@.... 
00000000: 3D OA D7 A3 70 FD 34 40 D7 07 07 11 =...p.4@.... 
00000000: 00 00 00 00 00 AO 63 40 D5 07 05 19 |. |  ...... c@.... 
00000000: CD CC CC CC CC 3C 5C 40 D7 07 0811  —  —  ....... Gites 
00000000: 66 66 66 66 66 FE 62 40 D4 07 06 05 fffff.b@.... 
00000000: 1F 85 EB 51 B8 FE 40 40 D6 07 09 1E ::2Q..@@:..: 
00000000: 00 00 00 00 00 40 5F 40 DC 07 0218 | |  ..... @ @.... 
00000000: 48 El 7A 14 AE 9F 67 40 D8 07 05 12 H.z...9Q.... 
00000000: CD CC CC CC CC 3C 5E 40 DC 07 0107 = — ...... 20. xs 
00000000: 00 00 00 00 00 00 67 40 D407 OBOE | . ...... g@.... 
00000000: 00 00 00 00 00 40 51 40 DC 07 04 OB | | . ..... @Q@.... 
00000000: 00 00 00 00 00 40 56 40 D7 07 07 OA . | ..... @V@.... 
00000000: 8F C2 F5 28 5C 7F 55 40 DB 07 01 16 cil VO... 
00000000: 00 00 00 00 00 00 32 40 DB 07 06 09 = ...... 20.... 
00000000: 66 66 66 66 66 7E 66 40 D9 07 0A 06 fffff~f@.... 
00000000: 48 El 7A 14 AE DF 68 40 D5 07 07 16 H.z...hQ.... 


Nous voyons tout d'abord que les octets 0x40 et 0x07 sont présent dans chaque 
fin. Le tout dernier octet est toujours dans l'intervalle 1..0x1F (1..31), j'ai vérifié. Le 
pénultieme octet est toujours dans l'intervalle 1..0xC (1..12). Ouah, ca ressemble à 
une date! L'année peut étre représentée comme une valeur 16-bit, et peut-étre que 
les 4 derniers octets sont une date (16 bits pour l'année, 8 bits pour le mois et les 8 
restants pour le jour)? Ox7DD est 2013, 0x7D5 est 2005, etc. Ca semble juste. Ceci 
est une date. Il y a 8 octets supplémentaires. À en juger par le fait que ceci est une 
base de données appelée orders, peut-étre s'agit-il d'une sorte de somme ici? J'ai 
essayé de les interpréter comme des réels en double précision IEEE 754 et ai affiché 
toutes les valeurs! 


Certaines sont: 
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Ca ressemble à des nombres réels 


Maintenant, nous pouvons afficher les noms, sommes et dates. 


plain: 

00000000: OD 00 FF FE 
S. 

00000010: 45 00 20 00 
y ff 

00000020: 66 66 66 9E 


46 00 52 00 41 00 4E 00 4B 00 49 


4A 00 4F 00 48 00 4E 00 53 00 66 


61 40 D4 07 06 01 


OrderID- 1 name= FRANKIE JOHNS sum- 140.95 date- 2004 / 


plain: 

00000000: OB 00 FF FE 
Goa 

00000010: 41 00 52 00 


00000020: 1B 40 D4 07 
OrderID- 2 name= LORI 


plain: 
00000000: 0A 00 FF FE 


Ga 
00000010: 49 00 47 00 
V ea 
00000020: D4 07 06 01 
OrderID- 3 name= GARY 


plain: 

00000000: OF 00 FF FE 
Goa 

00000010: 41 00 20 00 
Goa 

00000020: 59 00 48 El 


4C 00 4F 00 52 00 49 00 20 00 42 
52 00 4F 00 4E 00 CD CC CC CC CC 
06 01 

BARRON sum- 6.95 date- 2004 / 6 / 
47 00 41 00 52 00 59 00 20 00 42 


47 00 53 00 00 00 00 00 00 CO 65 


BIGGS sum= 174.0 date- 2004 / 6 / 


4D 00 45 00 4C 00 49 00 4E 00 44 
44 00 4F 00 48 00 45 00 52 00 54 


7A 14 AE FF 68 40 D4 07 06 02 


OrderID- 4 name- MELINDA DOHERTY sum- 199.99 date- 2004 


plain: 

00000000: OB 00 FF FE 
S e. 

00000010: 41 00 52 00 


00000020: 66 40 D4 07 


4C 00 45 00 4E 00 41 00 20 00 4D 


43 00 55 00 53 00 00 00 00 00 00 


06 03 


00 


00 


CC 


00 


40 


00 


60 


F.R 
E. .J.0 
fff.a@.. 
1 
..L.0. 
A.R.R.O. 
.Q.. 
G.A. 
I.G.G.S. 
..M.E 
A. .D.0 
Y.H.z 
/2 
.L.E 
A.R.C.U. 


.A.N.K.I2 
.H.N.S.7 
R.I. .B2 
N2 
R.Y. .B2 
ne 2 
.L. I.N.D2 
.H.E.R. T2 
..hQ.... 
.N.A. .M2 
S2 
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OrderID- 5 name= LENA MARCUS sum- 179.0 date= 2004 / 6 / 3 


En voir plus: https: //beginners.re/paywall/RE4B-source/current-tree//examples/ 
encrypted DB1/decrypted.full.with_data.txt.Oufiltré: https: //beginners.re/ 
paywall/RE4B-source/current-tree//examples/encrypted DB1/decrypted.short. 


txt. Ca semble correct. 


Ceci est une sorte de sérialisation POO, i.e., stockant différents types de valeurs 
dans un buffer binaire pour le stocker et/ou le transmettre. 


8.9.8 Bruit en fin de buffer 


La seule question qui reste est que, parfois, la fin est plus longue: 


00000000: OE 00 FF FE 54 00 48 00 45 00 52 00 45 00 53 00  ....T.H.E.R.E.S7 
Go. 

00000010: 45 00 20 00 54 00 55 00 54 00 54 00 4C 00 45 00 E. .T.U.T.T.L.E? 
Ve 

00000020: 66 66 66 66 66 1E 63 40 D4 07 07 1A 00 07 07 19 fffff.c@v 
Nara 


OrderID- 172 name= THERESE TUTTLE sum= 152.95 date- 2004 / 7 / 26 


(Les octets 00 07 07 19 ne sont pas utilisés et servent de remplissage.) 


00000000: OC 00 FF FE 4D 00 45 00 4C 00 41 00 4E 00 49 00 ....M.E.L.A.N.I2 
Goa 
00000010: 45 00 20 00 4B 00 49 00 52 00 4B 00 00 00 00 00 E. .K.I.R.K7 
SS E 
00000020: 00 20 64 40 D4 07 09 02 00 02 . d@...... 
OrderID- 286 name- MELANIE KIRK sum- 161.0 date- 2004/ 9/2 


(00 02 ne sont pas utilisés.) 


Aprés un examen rigoureux, on peut voir que le but à la fin de la fin est juste le reste 
d'un chiffrement précédent! 


Voici deux buffers consécutifs: 


00000000: 10 00 FF FE 42 00 4F 00 4E 00 4E 00 49 00 45 00 ....B.O.N.N,T.E2 
Goa 

00000010: 20 00 47 00 4F 00 4C 00 44 00 53 00 54 00 45 00 .G.0.L.D.S.T.E 
E 

00000020: 49 00 4E 00 9A 99 99 99 99 79 46 40 D4 07 07 19 I.N...... y FO? 
y 


OrderID- 171 name= BONNIE GOLDSTEIN sum= 44.95 date= 2004 / 7 / 25 


00000000: OE 00 FF FE 54 00 48 00 45 00 52 00 45 00 53 00  ....T.H.E.R.E.S7 
Go. 

00000010: 45 00 20 00 54 00 55 00 54 00 54 00 4C 00 45 00 E. .T.U.T.T.L.E? 
Ve 

00000020: 66 66 66 66 66 1E 63 40 D4 07 07 1A 00 07 07 19 fffff.c@v 
ETT 


OrderID- 172 name- THERESE TUTTLE sum- 152.95 date- 2004 / 7 / 26 
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(Les derniers octets 07 07 19 sont copiés du buffer précédent.) 


Un autre exemple de deux buffers consécutifs: 


00000000: OD 00 FF FE 4C 00 4F 00 52 00 45 00 4E 00 45 00 ....L.O.R.E.N.E7 
00000010: 20 88 4F 00 54 00 AF 00 4F 00 4C 00 45 09 CD CC .0.T.0.0.L.E2 
00000020: CC CC CC 3C SE 40 DA 07 09 02 sm Qus. 
OrderID= 285 name= LORENE OTOOLE sum= 120.95 date= 2004 / 9 / 2 

00000000: OC 00 FF FE 4D 00 45 00 4C 00 41 00 4E 00 49 00 ....M.E.L.A.N. I7 
00000010: 45 08 20 00 4B 00 49 00 52 00 4B 00 00 00 00 00 E. .K.L.R.K7 
00000020: 00 20 64 40 DA 07 09 02 00 02 dQ...... 


OrderID- 286 name= MELANIE KIRK sum- 161.0 date- 2004 / 9 / 2 


Le dernier octet 02 a été copié du buffer en texte clair précédent. 


C'est possible si le buffer utilisé lors du chiffrement est global et/ou s'il n'est pas 
mis à zéro entre chaque chiffrement. La taille du buffer final est aussi chaotique, 
néanmoins, le bogue reste sans conséquence car il n'affecte pas le processus de 
déchiffrement, qui ignore le bruit à la fin. C'est une erreur courante. II était présent 
dans OpenSSL (Heartbleed bug). 


8.9.9 Conclusion 


Résumé: Chaque rétro-ingénieur pratiquant doit étre familier avec la majorité des 
algorithmes ainsi que la majorité des modes de chiffrement. Quelques livres à ce 
sujet: 12.1.10 on page 1316. 


Le contenu chiffré de la base de données a été artificiellement construit par moi, pour 

les besoins dela démonstration. J'ai obtenu les nom et noms de famille les plus répan- 

dus au USA ici: http: //stackoverflow.com/questions/1803628/raw-list-of-person-names, 
et les ai combiné aléatoirement. Les dates et montants ont aussi été générés aléa- 

toirement. 


Tous les fichiers utilisés dans cette partie sont ici: https: //beginners.re/paywall/ 
RE4B- source/current-tree//examples/encrypted DB1. 


Néanmoins, j'ai observé de telles caractéristiques dans des logiciels réels. Cet exemple 
est basé dessus. 


8.9.10 Post Scriptum: brute-force IV 


Le cas que vous venez de voir a été construit artificiellement, mais il est basé sur 
des logiciels réels que j'ai rétro-ingéniéré. Lorsque j'ai travaillé dessus, j'ai d'abord 
remarqué que I'lV avait été généré en utilisant un nombre 32-bit, et je n'ai pas été 
capable de trouver un lien entre cette valeur et OrderlD. Donc j'ai utilisé le brute- 
force, ce qui est aussi possible ici. 
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Ce n'est pas un probléme d'énumérer toutes les valeurs 32-bit et d'essayer chacune 
d'elle comme base pour l'IV. Ensuite vous déchiffrez le premier bloc de 16 octets et 
vérifiez les octets à zéro, qui sont toujours à des places fixes. 


8.10 Overclocker le mineur de Bitcoin Cointerra 


Il y avait le mineur de Bitcoin Cointerra, ressemblant à ceci: 


BE IO Ss t 
Zong LINUX 
Pc 


Fig. 8.14: Carte 


Et il y avait aussi (peut-être leaké) l'utilitaire?? qui peut définir la fréquence d'horloge 
pour la carte. Il fonctionne sur une carte additionnelle BeagleBone Linux ARM (petite 
carte en bas de l'image). 


Et on m'avait demandé une fois s'il est possible de modifier cet utilitaire pour voir 
quelles sont les fréquences qui peuvent étre définies, et celles qui ne peuvent pas 
l'étre. Et est-il possible de l'ajuster? 


25Peut être téléchargé ici: https: //beginners. re/paywall/RE4B- source/current- tree//examples/ 
bitcoin miner/files/cointool-overclock 
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L'utilitaire doit être exécuté comme cela: ./cointool -overclock 0 0 900, où 900 
est la fréquence en MHz. Si la fréquence est trop grande, l'utilitaire affiche «Error 
with arguments » et se termine. 


Ceci est le morceau de code autour de la référence à la chaíne de texte «Error with 
arguments » : 


. text: 0000ABC4 STR R3, [R11,£var 28] 
.text:0000ABC8 MOV R3, #optind 
.text:0000ABDO LDR R3, [R3] 

. text: 0000ABD4 ADD R3, R3, #1 
.text:0000ABD8 MOV R3, R3,LSL#2 
.text:0000ABDC LDR R2, [R11,#argv] 
.text:0000ABEO ADD R3, R2, R3 

. text: 0000ABE4 LDR R3, [R3] 

. text: 0000ABE8 MOV RO, R3 ; nptr 
.text:0000ABEC MOV R1, 40 ; endptr 
.text:0000ABFO MOV R2, #0 ; base 
.text:0000ABF4 BL strtoll 
.text:0000ABF8 MOV R2, RO 

.text:0000ABFC MOV R3, R1 

.text : 0000AC00 MOV R3, R2 

. text: 0000AC04 STR R3, [R11,#var_2C] 

. text: 0000AC08 MOV R3, #optind 

. text: 0000AC10 LDR R3, [R3] 

. text: 0000AC14 ADD R3, R3, #2 

. text: 0000AC18 MOV R3, R3,LSL#2 

. text: 0000AC1C LDR R2, [R11,#argv] 

. text: 0000AC20 ADD R3, R2, R3 

. text: 0000AC24 LDR R3, [R3] 

. text: 0000AC28 MOV RO, R3 ; nptr 

. text: 0000AC2C MOV R1, #0 ; endptr 

. text: 0000AC30 MOV R2, #0 ; base 

. text: 0000AC34 BL strtoll 

. text: 0000AC38 MOV R2, RO 

. text: 0000AC3C MOV R3, R1 

. text: 0000AC40 MOV R3, R2 

.text:0000AC44 STR R3, [R11,#third argument] 
. text: 0000AC48 LDR R3, [R11,#var_28] 

. text: 0000AC4C CMP R3, #0 

.text:0000AC50 BLT errors with arguments 
.text:0000AC54 LDR R3, [R11,£var 28] 
.text:0000AC58 CMP R3, 71 

.text:0000AC5C BGT errors with arguments 
.text:0000AC60 LDR R3, [R11,£var 2C] 
.text:0000AC64 CMP R3, #0 

.text:0000AC68 BLT errors with arguments 
.text:0000AC6C LDR R3, [R11,£var 2C] 
.text:0000AC70 CMP R3, #3 

.text:0000AC74 BGT errors with arguments 


.text:0000AC78 LDR R3, [R11,#third argument] 
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.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0000AC98 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0000ACCC 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0000ACFO 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:0000AD20 


.text 


.text: 
.text: 
.text: 
.text: 


0000AC7C 
0000AC80 
0000AC84 
0000AC88 
0000AC8C 
0000AC90 
0000AC94 


0000ACAO0 
0000ACA4 
0000ACA8 
OOOOACAC 
0000ACBO 
0000ACB4 
0000ACB8 
0000ACBC 
0000ACCO 
0000ACC4 
0000ACC4 
0000ACC4 
0000ACC4 
0000ACC8 


0000ACDO 
0000ACD4 
0000ACD8 
0000ACEO 
0000ACE4 
0000ACE8 
OOOGACEC 
OOOGACEC 
OOOOACEC 
OOOOACEC 


0000ACF4 
0000ACF8 
0000ACFC 
0000AD00 
0000AD04 
0000AD08 
0000AD08 
0000AD08 
0000AD08 
0000ADOC 
0000AD10 
0000AD14 
0000AD18 
0000AD1C 


0000AD24 
0000AD24 
0000AD24 
0000AD24 


CMP R3, #0x31 
BLE errors with arguments 
LDR R2, [R11,#third argument] 
MOV R3, $950 
CMP R2, R3 
BGT errors with arguments 
LDR R2, [R11,#third argument] 
MOV R3, £0x51EB851F 
SMULL R1, R3, R3, R2 
MOV R1, R3,ASR#4 
MOV R3, R2,ASR#31 
RSB R3, R3, R1 
MOV R1, $50 
MUL R3, R1, R3 
RSB R3, R3, R2 
CMP R3, #0 
BEQ loc ACEC 
errors with arguments 
LDR R3, [R11,#argv] 
LDR R3, [R3] 
MOV RO, R3 ; path 
BL . Xpg basename 
MOV R3, RO 
MOV RO, #aSErrorWithArgu ; format 
MOV R1, R3 
BL printf 
B loc ADD4 
loc ACEC ; CODE XREF: main+66C 
LDR R2, [R11,#third argument] 
MOV R3, #499 
CMP R2, R3 
BGT loc AD08 
MOV R3, #0x64 
STR R3, [R11,#unk constant] 
B jump to write power 
loc AD08 ; CODE XREF: main+6A4 
LDR R2, [R11,#third argument] 
MOV R3, $799 
CMP R2, R3 
BGT loc AD24 
MOV R3, #0x5F 
STR R3, [R11,#unk constant] 
B jump to write power 
loc AD24 ; CODE XREF: main+6C0 
LDR R2, [R11,#third argument] 
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.text:0000AD28 MOV R3, #899 

.text:0000AD2C CMP R2, R3 

.text:0000AD30 BGT loc AD40 

.text:0000AD34 MOV R3, #0x5A 
.text:0000AD38 STR R3, [R11,#unk constant] 
.text:0000AD3C B jump to write power 


,text:0000AD40 ; -«s------- eorr ee Tee eere eA emere sere hadaa ada amaaa 
.text:0000AD40 


.text:0000AD40 loc AD40 ; CODE XREF: main+6DC 
.text:0000AD40 LDR R2, [R11,#third argument] 
.text:0000AD44 MOV R3, 4999 

.text:0000AD48 CMP R2, R3 

. text: 0000AD4C BGT loc_AD5C 

. text: 0000AD50 MOV R3, 40x55 

.text:0000AD54 STR R3, [R11,#unk constant] 
.text:0000AD58 B jump to write power 


,text:0000AD5C ; ---------- crc re rr ee re tee eere reum 
.text:0000AD5C 


.text:0000AD5C loc AD5C ; CODE XREF: main+6F8 
.text:0000AD5C LDR R2, [R11,#third argument] 
.text:0000AD60 MOV R3, #1099 

.text:0000AD64 CMP R2, R3 

.text:0000AD68 BGT jump to write power 
.text:0000AD6C MOV R3, 40x50 

.text:0000AD70 STR R3, [R11,#unk constant] 
.text:0000AD74 

.text:0000AD74 jump to write power ; CODE XREF: main+6B0 
.text:0000AD74 ; main+6CC ... 
.text:0000AD74 LDR R3, [R11,£var 28] 
.text:0000AD78 UXTB R1, R3 

.text:0000AD7C LDR R3, [R11,£var 2C] 
.text:0000AD80 UXTB R2, R3 

.text:0000AD84 LDR R3, [R11,#unk constant] 
.text:0000AD88 UXTB R3, R3 

.text : 0000AD8C LDR RO, [R11,#third argument] 
.text : 0000AD90 UXTH RO, RO 

. text: 0000AD94 STR RO, [SP,#0x44+var_ 44] 
.text:0000AD98 LDR RO, [R11,£var 24] 
.text:0000AD9C BL write power 

.text:0000ADAO0 LDR RO, [R11,#var 24] 

. text : 0000ADA4 MOV R1, #0x5A 

.text : 0000ADA8 BL read loop 

.text:0000ADAC B loc ADDA 


.rodata:0000B378 aSErrorwithArgu DCB "%s: Error with arguments",0xA,0 ; DATA 
XREF: main+684 


Les noms de fonctions étaient présents dans les informations de débogage du binaire 
original, comme write power, read loop. Mais j'ai nommé les labels à l'intérieur 
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des fonctions. 


Le nom optind semble familier. Il provient de la bibliothèque *NIX getopt qui sert 
à traiter les arguments de la ligne de commande- bien, c'est exactement ce qui se 
passe dans ce code. Ensuite, le 3ème argument (où la valeur de la fréquence est 
passée) est converti d'une chaíne vers un nombre en utilisant un appel à la fonction 
strtoll(). 


La valeur est ensuite encore comparée par rapport a diverses constantes. En OxA- 
CEC, elle est testée, si elle est inférieure ou égale à 499, et si c'est le cas, 0x64 est 
passé à la fonction write power() (qui envoie une commande par USB en utilisant 
send msg()). Si elle est plus grande que 499, un saut en OxADO8 se produit. 


En OxADOS on teste si elle est inférieure ou égale à 799. En cas de succés Ox5F est 
alors passé à la fonction write power(). 


Il y a d'autres tests: par rapport à 899 en OxAD24, à 0x999 en OxAD40 et enfin, 
à 1099 en OxAD5C. Si la fréquence est inférieure ou égale à 1099, 0x50 est pas- 
sé (en OxAD6C) à la fonction write power(). Et il y a une sorte de bug. Si la va- 
leur est encore plus grande que 1099, la valeur elle-même est passée à la fonction 
write power(). Oh, ce n'est pas un bug, car nous ne pouvons pas arriver là: la va- 
leur est d'abord comparée à 950 en OxAC88, et si elle est plus grande, un message 
d'erreur est affiché et l'utilitaire s'arréte. 


Maintenant, la table des fréquences en MHz et la valeur passée à la fonction write power(): 


MHz héxadecimal | décimal 
499MHz 0x64 100 
799MHz Ox5f 95 
899MHz Ox5a 90 
999MHz 0x55 85 
1099MHz | 0x50 80 


Il semble que la valeur passée à la carte décroit lorsque la fréquence croit. 


Maintenant, nous voyons que la valeur de 950MHz est codée en dur, au moins dans 
cet utilitaire. Pouvons-nous le truquer? 


Retournons à ce morceau de code: 


.text:0000AC84 LDR R2, [R11,#third argument] 

.text:0000AC88 MOV R3, #950 

.text:0000AC8C CMP R2, R3 

.text:0000AC90 BGT errors with arguments ; j'ai modifié ici en 00 00 
00 00 


Nous devons désactiver l'instruction de branchement BGT en OxAC9O0. Et ceci est du 
ARM en mode ARM, car, comme on le voit, toutes les adresses augmentent par 4, 
i.e, chaque instruction a une taille de 4 octets. L'instruction NOP (no operation) en 
mode ARM est juste quatre octets à zéro: 00 00 00 00. Donc en écrivant quatre 
octets à zéro à l'adresse 0xAC90 (ou à l'offset 0x2C90 dans le fichier), nous pouvons 
désactiver le test. 
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Maintenant, il est possible de définir la fréquence jusqu'à 1050MHz. Et méme plus, 
mais, à cause du bug, si la valeur en entrée est plus grande que 1099, la valeur telle 
quelle en MHz sera passée à la carte, ce qui est incorrect. 


Je ne suis pas allé plus loin, mais si je devais, j'essayerai de diminuer la valeur qui 
est passée à la fonction write power(). 


Maintenant, le morceau de code effrayant que j'ai passé en premier: 


.text:0000AC94 LDR R2, [R11,#third argument] 
.text:0000AC98 MOV R3, #0x51EB851F 

.text:0000ACAO SMULL R1, R3, R3, R2 ; R3=3rg arg/3.125 
.text:0000ACA4 MOV R1, R3,ASR#4 ; R1=R3/16=3rg arg/50 
.text:0000ACA8 MOV R3, R2,ASR#31 ; R3-MSB(3rg arg) 
.text:0000ACAC RSB R3, R3, R1 ; R3=3rd_arg/50 
.text:0000ACBO MOV R1, 450 

.text : 0000ACB4 MUL R3, R1, R3 ; R3=50*(3rd arg/50) 

. text: 0000ACB8 RSB R3, R3, R2 

. text: 0000ACBC CMP R3, 40 

.text:0000ACCO BEQ loc ACEC 


. text : 0000ACC4 
.text:0000ACC4 errors with arguments 


La division via la multiplication est utilisée ici, et la constante est Ox51EB851F. Je me 
suis écrit un petit calculateur pour programmeur?*. Et il est capable de calculer le 
modulo inverse. 


modinv32(0x51EB851F) 
Warning, result is not integer: 3.125000 
(unsigned) dec: 3 hex: 0x3 bin: 11 


Cela signifie que l'instruction SMULL en OxACAO divise le 3ème argument par 3.125. 
En fait, tout ce que la fonction modinv32() de mon calculateur fait est ceci: 


1 932 


input ^ 5; 
l x input 


Ensuite il y a es décalages additionnels et maintenant nous voyons que le 3éme 
argument est simplement divisé par 50. Et ensuite il à nouveau multiplié par 50. 
Pourquoi? Ceci est un simple test, pour savoir si la valeur entrée est divisible par 50. 
Si la valeur de cette expression est non nulle, x n'est pas divisible par 50: 


T 


z- (Š) 50) 


Ceci est en fait une manière simple de calculer le reste de la division. 


Et alors, si le reste est non nul, un message d'erreur est affiché. Donc cet utilitaire 
prend des fréquences comme 850, 900, 950, 1000, etc., mais pas 855 ou 911. 


26https://yurichev.com/progcalc/ 
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C'est ca! Si vous faites quelque chose comme ca, soyez avertis que vous pouvez en- 
dommager votre carte, tout comme en cas d'overclocking d'autres éléments comme 
les CPUs, GPU?’s, etc. Si vous avez une carte Cointerra, faites ceci à votre propre 
risque! 


8.11 Casser un simple exécutable de chiffrement 
de code 

Nous avons un fichier exécutable qui est chiffré par du chiffrement relativement 

simple. Il est ici (seule la section exécutable est laissée ici). 


Tout d'abord, tout ce que fait la fonction de chiffrement, c'est d'ajouter l'index de la 
position dans le buffer à l'octet. Voici comment ca peut étre implémenté: 


Listing 8.9 : Python script 


#!/usr/bin/env python 
def e(i, k): 
return chr ((ord(i)+k) % 256) 


def encrypt(buf): 
return e(buf[0], 0)+ e(buf[1], 1)+ e(buf[2], 2) + e(buf[3], 3)+ e(buf 2 
G [4], 4)* e(buf[5], 5)+ e(buf[6], 6)+ e(buf[7], 7)+ 
e(buf[8], 8)+ e(buf[9], 9)+ e(buf[10], 10)+ e(buf[11], 11)+ e(z 
S buf[12], 12)+ e(buf[13], 13)+ e(buf[14], 14)+ e(buf[15], 15) 


Ainsi, si vous chiffrez un buffer avec 16 zéros, vous obtiendrez 0, 1, 2, 3 ... 12, 13, 
14, 15. 


La Propagating Cipher Block Chaining (PCBC) est aussi utilisée, voici comment elle 
fonctionne: 


?7 Graphics Processing Unit 
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Plaintext Plaintext Plaintext 


CIIITITITITIT] COIN ee 2 


Initialization Vector (IV) 
ONN e p 
block cipher block cipher block cipher 
Key Key Key 


OT LLTITIITITITIT] LLITITIITITIT] 
Ciphertext Ciphertext Ciphertext 


Propagating Cipher Block Chaining (PCBC) mode encryption 


Fig. 8.15: Chiffrement avec Propagating Cipher Block Chaining (l'image provient d'un 
article Wikipédia) 


Le probléme est de retrouver l'IV. La force brute n'est pas une option, car l'IV est 
trop long (16 octets). Voyons s'il est possible de recouvrer l'IV pour un fichier binaire 
exécutable arbitraire? 


Essayons la simple analyse de fréquence. Ceci est du code exécutable 32-bit x86, 
donc collectons des statistiques sur les octets et les opcodes les plus fréquents. J'ai 
essayé le fichier géant oracle.exe d' Oracle RDBMS version 11.2 pour windows x86 
et j'ai trouvé que l'octet le plus fréquent (pas de surprise) est zéro ( 1096). L'octet 
suivant le plus fréquent est (encore une fois, sans surprise) OxFF ( 596). Le suivant 
est Ox8B ( 5%). 


Ox8B est l'opcode de MOV, ceci est en effet l'une des instructions x86 les plus fré- 
quentes. Maintenant, que dire de la popularité de l'octet zéro? Si le compilateur doit 
encoder une valeur plus grande que 127, il doit utiliser un déplacement 32-bit au 
lieu d'un de 8-bit, mais les grandes valeurs sont trés rares (2.1.8 on page 584), donc 
il est complété par des zéros. C'est le cas au moins avec LEA, MOV, PUSH, CALL. 


Par exemple: 


8D BO 28 01 00 00 lea esi, [eax+128h] 
8D BF 40 38 00 00 lea edi, [edi+3840h] 


Les déplacements plus grand que 127 sont trés fréquents, mais ils excédent rare- 
ment 0x10000 (en effet, des buffers mémoire/structures aussi grands sont aussi 
rares). 


Méme chose avec MOV, les grandes constantes sont rares, les plus utilisées sont O, 
1, 10, 100, 2”, et ainsi de suite. Le compilateur doit compléter les petites constantes 
avec des zéros pour les encoder comme des valeurs 32-bit: 


BF 02 00 00 00 mov edi, 2 
BF 01 00 00 00 mov edi, 1 
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Maintenant parlons des octets 00 et OxFF combinés: les sauts (conditionnels inclus) 
et appels peuvent transférer le flux d'exécution en avant ou en arriére, mais trés 
souvent, dans les limites du module exécutable courant. Si c'est en avant, le dépla- 
cement n'est pas trés grand et il y a des zéros ajoutés. Si c'est en arriére, le déplace- 
ment est représenté par une valeur négative, donc complétée par des octets OxFF. 
Par exemple, transfert du flux d'exécution en avant: 


E8 43 0C 00 00 call _functionl 
E8 5C 00 00 00 call _function2 
OF 84 FO OA 00 00 jz loc 4F09A0 
OF 84 EB 00 00 00 jz loc_4EFBB8 
En arriére: 

E8 79 0C FE FF call _functionl 
E8 F4 16 FF FF call _function2 
OF 84 F8 FB FF FF jz loc 8212BC 
OF 84 06 FD FF FF jz loc FF1E7D 


L'octet OxFF se rencontre aussi trés souvent dans des déplacements négatifs, comme 
ceux-ci: 


8D 85 1E FF FF FF lea eax, [ebp-0E2h] 
8D 95 F8 5C FF FF lea edx, [ebp-0A308h] 


Jusqu'ici, tout va bien. Maintenant nous devons essayer diverses clefs 16-octet, dé- 
chiffrer la section exécutable et mesurer les occurences des octets 0, OxFF et Ox8B. 
Gardons en vue la facon dont le déchiffrement PCBC fonctionne: 


Ciphertext Ciphertext Ciphertext 
OT] LITITITITITTD OI 


block cipher block cipher block cipher 
Key decryption "uy decryption Key decryption 


Initialization Vector (IV) $ 


OIO — e 
on LELILILIILLLD CII) 
Plaintext Plaintext Plaintext 


Propagating Cipher Block Chaining (PCBC) mode decryption 


Fig. 8.16: Propagating Cipher Block Chaining decryption (l’image provient d'un article 
Wikipédia) 


La bonne nouvelle est que nous n'avons pas vraiment besoin de déchiffrer l'en- 
semble des données, mais seulement slice par slice, ceci est exactement comment 
j'ai procédé dans mon exemple précédent: 9.1.5 on page 1218. 


1137 
Maintenant j'essaye tous les octets possible (0..255) pour chaque octet dans la clef 
et je prends l'octet produisant le plus grande nombre d'octets Ox0/OxFF/Ox8B dans 
le slice déchiffré: 


#!/usr/bin/env python 
import sys, hexdump, array, string, operator 


KEY LEN-16 


def chunks(l, n): 
# split n by l-byte chunks 
# https://stackoverflow.com/q/312443 
n - max(1, n) 
return [l[i:i + n] for i in range(0, len(1), n)] 


def read file(fname): 
file=open(fname, modez'rb') 
content-file.read() 
file.close() 
return content 


def decrypt byte (c, key): 
return chr((ord(c)-key) % 256) 


def XOR PCBC step (IV, buf, k): 

prev-IV 

rtz"" 

for c in buf: 
new c-decrypt byte(c, k) 
plain=chr(ord(new_c)*ord(prev) ) 
prev=chr(ord(c)*ord(plain) ) 
rt=rt+plain 

return rt 


each Nth byte-[""]*KEY LEN 


content-read file(sys.argv[1]) 
# split input by 16-byte chunks: 
all chunksschunks(content, KEY LEN) 
for c in all chunks: 
for i in range(KEY LEN): 
each Nth byte[i]zeach Nth byte[i] + c[i] 


# try each byte of key 
for N in range(KEY LEN): 
print "N=", N 
stat={} 
for i in range(256): 
tmp_key=chr(i) 
tmp-XOR PCBC step(tmp key,each Nth byte[N], N) 
# count 0, FFs and 8Bs in decrypted buffer: 
important bytes=tmp.count("\x00")+tmp.count("\xFF')+tmp.count("\x8B 
Vc) 
stat[i]-important bytes 
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sorted stat = sorted(stat.iteritems(), key=operator.itemgetter(1), 2 
S reverse-True) 
print sorted stat[0] 


(Le code source peut étre téléchargé ici.) 


Je le lance et voici une clef pour laquelle le nombre d'octets 0/OxFF/Ox8B dans le 
buffer déchiffré est maximum: 


N- 0 
(147, 1224) 
N= 1 
(94, 1327) 
N= 2 
(252, 1223) 
N= 3 
18, 1266) 


nS 
Pp 
N 
© 
[te] 


Pp 
w 
N 
© 


1 


, 1251) 


WU © UY.  N U1- 


112, 1223) 


(143, 1177) 
N= 11 

(108, 1286) 
N= 12 

(10, 1164) 
N= 13 

(3, 1271) 
N= 14 

(128, 1253) 
N= 15 

(232, 1330) 


Écrivons un utilitaire de déchiffrement avec la clef obtenue: 


#!/usr/bin/env python 
import sys, hexdump, array 


def xor_strings(s,t): 
# https://en.wikipedia.org/wiki/XOR cipher#Example implementation 
"""xor two strings together 
return "".join(chr(ord(a)^ord(b)) for a,b in zip(s,t)) 


IV=array.array('B', [147, 94, 252, 218, 38, 192, 199, 213, 225, 112, 143, Y 
& 108, 10, 3, 128, 232]).tostring() 
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def 


def 


def 


def 


chunks(l, n): 
n - max(1, n) 
return [l[i:i + n] for i in range(0, len(1), n)] 


read file(fname): 
file=open(fname, mode='rb') 
content=file. read() 
file.close() 

return content 


decrypt byte(i, k): 
return chr ((ord(i)-k) 9 256) 


decrypt (buf): 
return "".join(decrypt byte(buf[i], i) for i in range(16)) 


fout=open (sys.argv[2], mode='wb') 


prev-IV 
content-read file(sys.argv[1]) 


tmp- 


chunks(content, 16) 


for c in tmp: 


new c-decrypt(c) 

p-xor strings (new c, prev) 
prev-xor strings(c, p) 
fout.write(p) 


fout.close() 


(Le code source peut étre téléchargé ici.) 


Vérifions le fichier résultant: 


$ objdump -b binary -m i386 -D decrypted.bin 


5 8b ff mov “edi,%edi 

7 55 push  %ebp 

8: 8b ec mov *sesp ,?sebp 

a: 51 push  %ecx 

b: 53 push %ebx 

C 33 db xor %ebx , Sebx 

e: 43 inc %ebx 

f: 84 1d a0 e2 05 01 test  %bl,0x105e2a0 
15: 75 09 jne 0x20 

17: ff 75 08 pushl 0x8(%ebp) 

la: ff 15 b0 13 00 01 call — *0x10013b0 
20: 6a 6c push $0x6c 

22: ff 35 54 dO 01 01 pushl 0x101d054 

28: ff 15 b4 13 00 01 call — *0x10013b4 
2e: 89 45 fc mov *seax , - Ox4 (*sebp ) 
31: 85 c0 test  %eax,%eax 


33: Of 84 d9 00 00 00 je 0x112 
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39: 56 push  S%esi 

3a: 57 push %edi 

3b: 6a 00 push $0x0 

3d: 50 push  $seax 

3e: ff 15 b8 13 00 01 call *0x10013b8 

44: 8b 35 bc 13 00 01 mov 0x10013bc,%esi 
4a: 8b f8 mov *seax , sedi 

4c: al e0 e2 05 01 mov 0x105e2e0,%eax 
51: 3b 05 e4 e2 05 01 cmp 0x105e2e4,%eax 
57: 75 12 jne 0x6b 

59: 53 push %ebx 

5a: 6a 03 push  $0x3 

5c: 57 push  %edi 

5d: ff d6 call *%esi 


Oui, ceci semble étre un morceau correctement désassemblé de code x86. Le fichier 
déchiffré entier peut étre téléchargé ici. 


En fait, ceci est la section text du regedit.exe de Windows 7. Mais cet exemple est 
basé sur un cas réel que j'ai rencontré, seul l'exécutable est différent (et la clef), 
l'algorithme est le méme. 


8.11.1 Autres idées à prendre en considération 


Et si j'avais échoué avec cette simple analyse des fréquences? Il y a d'autres idées 
sur la facon de mesurer l'exactitude de code x86 déchiffré/décompressé: 


* De nombreux compilateurs modernes alignent le début des fonctions sur une 
limite 16-bits. Donc l'espace libre avant est rempli avec de NOPs (0x90) ou 
d'autres instructions avec des opcodes connus: .1.7 on page 1347. Ou des ins- 
tructions INT3 (OxCC). 


Peut-étre que le pattern le plus fréquent dans tout langage d'assemblage est 
l'appel de fonction: 

PUSH chain / CALL / ADD ESP, X. Cette séquence peut facilement étre dé- 
tectée et trouvée. J'ai méme collecté des statistiques sur le nombre moyen d'ar- 
guments des fonctions: 11.3 on page 1289. (Ainsi, ceci est la longueur moyenne 
d'une série d'instructions PUSH.) 


En savoir plus sur le code désassemblé incorrectement/correctement: 5.11 on page 944. 
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8.12 SAP 


8.12.1 A propos de la compression du trafic réseau par le 
client SAP 


(Tracer la connexion entre la variable d'environnement TDW_NOCOMPRESS SAPGUI?® 
et la fenétre pop-up génante et ennuyeuse et la routine de compression de données 
actuelle.) 


On sait que le trafic réseau entre le SAPGUI et SAP n'est pas chiffré par défaut, mais 
compressé (voir ici?? et ici??). 


Il est aussi connue que mettre la variable d'environnement TDW NOCOMPRESS à 1, 
permet d'arréter la compression des paquets réseau. 


Mais vous verrez toujours l'ennuyeuse fenétre pop-up, qui ne peut pas étre fermée: 


E SAP 
e «-qBecee BAR 886868 44 o 
SAP 
New password 
Client 001 | Information 
Welcome to the IDES ECC 6.0 incl. EhP4 
User M 
Password A A E A NT 
[Sapgui 720 [/H/SAP 
Language 


- Environment information: 
© data compression switched off 
For maximum data security delete 
the setting[s] as soon as possible ! 


Fig. 8.17: Screenshot 


Voyons si nous pouvons supprimer cette fenétre. 


Mais avant, voyons ce que nous savons déja: 


28client SAP GUI 
22http://blog.yurichev.com/node/44 
30blog.yurichev.com 
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Premiérement: nous savons que la variable d'environnement TDW NOCOMPRESS 
est vérifiée quelque part dans le client SAPGUI. 


Deuxiémement: une chaine comme «data compression switched off » doit s'y trouver 
quelque part. 


Avec l'aide du gestionnaire de fichier FAR?! nous pouvons trouver que deux de ces 
chaînes sont stockées dans le fichier SAPguilib.dll. 


Donc ouvrons SAPguilib.dll dans IDA et cherchons la chaine TDW NOCOMPRESS. Oui, 
elle s'y trouve et il n'y a qu'une référence vers elle. 


Nous voyons le morceau de code suivant (tous les offsets de fichiers sont valables 
pour SAPGUI 720 win32, fichier SAPguilib.dll version 7200,1,0,9009) : 


.text:6440D51B lea eax, [ebp+2108h+var_211C] 

.text:6440D51E push eax ; int 

.text:6440D51F push offset aTdw nocompress ; 
"TDW NOCOMPRESS" 

.text:6440D524 mov byte ptr [edi+15h], 0 

.text:6440D528 call chk env 

.text:6440D52D pop ecx 

.text:6440D52bE pop ecx 

.text:6440D52F push offset byte 64443AF8 

.text:6440D534 lea ecx, [ebp+2108h+var 211C] 

; demangled name: int ATL::CStringT::Compare(char const *)const 

.text:6440D537 call ds:mfc90 1603 

. text : 6440D53D test eax, eax 

.text:6440D53F jz short loc 6440D55A 

.text:6440D541 lea ecx, [ebp+2108h+var 211C] 

; demangled name: const char* ATL::CSimpleStringT::operator PCXSTR 

.text:6440D544 call ds:mfc90 910 

. text: 6440D54A push eax ; Str 

.text:6440D54B call ds:atoi 

.text:6440D551 test eax, eax 

.text:6440D553 setnz al 

.text:6440D556 pop ecx 

. text: 6440D557 mov [edi+15h], al 


La chaine renvoyée par chk_env() via son second argument est ensuite traitée par 
la fonction de chaine MFC et ensuite atoi()?? est appelée. Aprés ca, la valeur nu- 
mérique est stockée en edi+15h. 


Jetons aussi un œil à la fonction chk env() (nous avons donné ce nom manuelle- 
ment) : 


.text:64413F20 ; int cdecl chk env(char *VarName, int) 


.text:64413F20 chk env proc near 
.text:64413F20 
.text:64413F20 DstSize = dword ptr -0Ch 


3lhttp://www.farmanager.com/ 
32fonction C standard qui convertit les chiffres d'une chaine en un nombre 


1143 


text: 
:64413F20 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


64413F20 


64413F20 
64413F20 
64413F20 
64413F20 
64413F21 
64413F23 
64413F26 
64413F2D 
64413F34 
64413F39 


var 8 
DstBuf 
VarName 
arg 4 


ptr -8 
ptr -4 
ptr 8 
ptr OCh 


ebp 

ebp, esp 

esp, OCh 
[ebp+DstSize], 0 
[ebp+DstBuf], 0 
offset unk_6444C88C 
ecx, [ebptarg 4] 


(demangled name) ATL::CStringT::operator-(char const *) 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:64413F58 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 


64413F3C 
64413F42 
64413F45 
64413F46 
64413F49 
64413F4A 
64413F4D 
64413F4E 
64413F51 
64413F52 


64413F5B 
64413F5E 
64413F62 
64413F64 
64413F66 
64413F68 
64413F68 
64413F68 
64413F6C 
64413F6E 
64413F70 
64413F72 
64413F72 
64413F72 
64413F75 
64413F76 


loc 64413F68: 


loc 64413F72: 


call 
mov 
push 
mov 
push 
mov 
push 
lea 
push 
call 
add 
mov 
cmp 
jz 
xor 
jmp 


cmp 
jnz 
xor 
jmp 


mov 
push 
mov 


ds:mfc90 820 

eax, [ebp+VarName] 

eax ; VarName 
ecx, [ebp+DstSize] 

ecx ; DstSize 
edx, [ebp+DstBuf] 

edx ; DstBuf 
eax, [ebp+DstSize] 

eax ; ReturnSize 
ds:getenv s 

esp, 10h 

[ebp+var_8], eax 
[ebp+var 8], 0 

short loc 64413F68 

eax, eax 

short loc 64413FBC 


[ebp+DstSize], 0 
short loc 64413F72 
eax, eax 

short loc 64413FBC 


ecx, [ebp+DstSize] 
ecx 
ecx, [ebptarg 4] 


; demangled name: ATL::CSimpleStringT«char, 1>::Preallocate(int) 


.text: 
.text: 
.text: 
.text: 
:64413F86 


. text 


.text: 
.text: 
.text: 
.text: 
.text: 


64413F79 
64413F7F 
64413F82 
64413F85 


64413F89 
64413F8A 
64413F8D 
64413F8E 
64413F91 


call 
mov 
mov 
push 
mov 
push 
mov 
push 
lea 
push 


ds:mfc90 2691 
[ebp+DstBuf], eax 
edx, [ebp+VarName] 


edx ; VarName 
eax, [ebp+DstSize] 

eax ; DstSize 
ecx, [ebp+DstBuf] 

ecx ; DstBuf 
edx, [ebp+DstSize] 

edx ; ReturnSize 


1144 


.text:64413F92 call ds:getenv s 
.text:64413F98 add esp, 10h 
.text:64413F9B mov [ebp+var 8], eax 
.text:64413F9E push OFFFFFFFFh 
.text:64413FA0 mov ecx, [ebp+arg 4] 

; demangled name: ATL::CSimpleStringT::ReleaseBuffer(int) 
.text:64413FA3 call ds:mfc90 5835 
.text:64413FA9 cmp [ebp+var 8], 0 
.text:64413FAD jz short loc 64413FB3 
.text:64413FAF xor eax, eax 
.text:64413FB1 jmp short loc 64413FBC 


.text:64413FB3 
.text:64413FB3 loc 64413FB3: 
.text:64413FB3 mov ecx, [ebp+arg 4] 


; demangled name: const char* ATL::CSimpleStringT::operator PCXSTR 
.text:64413FB6 call ds:mfc90 910 

.text:64413FBC 

.text:64413FBC loc 64413FBC: 

.text:64413FBC 


.text:64413FBC mov esp, ebp 
.text:64413FBE pop ebp 
.text:64413FBF retn 
.text:64413FBF chk env endp 


Oui. La fonction getenv s()?? 
est une version de Microsoft à la sécurité avancée de getenv()?^. 
Il y a quelques manipulation de chaine MFC. 


De nombreuses autres variables d'environnement sont également testées. Voici une 
liste de toutes les variables qui sont testé et ce que SAPGUI écrirait dans son fichier 
de log, lorsque les traces sont activées: 


33 
MSDN 
34Fonction de la bibliothéque C standard renvoyant une variable d'environnement 
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DPTRACE 
TDW_HEXDUMP 
TDW_WORKDIR 
TDW_SPLASHSRCEENOFF 


“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 
“GUI-OPTION: 


TDW_REPLYTIMEOUT 
TDW_PLAYBACKTIMEOUT 
TDW_NOCOMPRESS 
TDW_EXPERT 


TDW_PLAYBACKPROGRESS “GUI-OPTION: 
TDW_PLAYBACKNETTRAFFIC | “GUI-OPTION: 
TDW_PLAYLOG “GUI-OPTION: 
TDW_PLAYTIME “GUI-OPTION: 
TDW LOGFILE "GUI-OPTION: 
TDW WAN "GUI-OPTION: 


"GUI-OPTION: 
"GUI-OPTION: 
"GUI-OPTION: 
"GUI-OPTION: 
"GUI-OPTION: 
"GUI-OPTION: 
"GUI-OPTION: 


TDW FULLMENU 

SAP CP / SAP. CODEPAGE 
UPDOWNLOAD CP 

SNC PARTNERNAME 

SNC QOP 

SNC LIB 

SAPGUI INPLACE 


Trace set to 9od" 

Hexdump enabled" 

working directory ‘%s”’ 

Splash Screen Off" 

Splash Screen On" 

reply timeout %d milliseconds" 
PlaybackTimeout set to %d milliseconds" 
no compression read" 

expert mode" 

PlaybackProgress" 
PlaybackNetTraffic” 
/PlayLog is YES, file 96s" 

/PlayTime set to %d milliseconds" 
TDW LOGFILE ‘%s”’ 

WAN - low speed connection enabled" 
FullMenu enabled" 

SAP CODEPAGE ‘%d"' 
UPDOWNLOAD CP '9?6d"* 

SNC name ‘%s”’ 

SNC QOP ‘%s”’ 

SNC is set to: %s” 
environment variable SAPGUI INPLACE is on" 


La configuration de chaque variable est écrit dans le tableau via le pointeur dans le 
registre EDI. EDI est renseigné avant l'appel à la fonction: 


.text:6440EE00 lea 
here like 40x15... 

ext:6440EE03 lea 
.text:6440EE06 call 
.text : 6440EE0B mov 
.text:6440EE0D xor 
.text:6440EEO0F cmp 
.text:6440EE11 jz 
. text: 6440EE13 push 
. text: 6440EE14 push 


stopped after commandline interp".. 
. text: 6440EE19 push 
. text: 6440EE1F call 


edi, [ebp+2884h+var 2884] 
ecx, [esi+24h] 

load command line 

edi, eax 

ebx, ebx 

edi, ebx 

short loc 6440EE42 

edi 

offset aSapguiStoppedA ; 


; options 


"Sapgui 


dword 644F93E8 
FEWTraceError 


Maintenant, pouvons-nous trouver la chaine data record mode switched on? 


Oui, et la seule référence est dans 
CDwsGui::PrepareInfoWindow(). 


Comment connaissons-nous les noms de classe/méthode? Il y a beaucoup d'appels 
spéciaux de débogage qui écrivent dans les fichiers de log, comme: 


.text:64405160 
.text:64405166 
"NnCDwsGui 


push 
push 


.text:6440516B push 
.text:64405171 call 
.text:64405176 add 


::PrepareInfoWindow: sapgui env". 


dword ptr [esi+2854h] 
offset aCdwsguiPrepare ; 


dword ptr [esi+2848h] 
dbg 


esp, OCh 
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.. OÙ: 


.text:6440237A p 
.text:6440237B 


ush eax 


push offset aCclientStart 6 ; 


d sag! erts set shortcut user to '%". 


.text:64402 
.text:64402383 C 
.text:64402388 a 


dword ptr [edi+4] 
all dbg 
dd esp, OCh 


C'est trés utile. 


Voyons le contenu de la fonction de cette fenétre pop-up ennuyeuse: 


.text:64404F4F CDwsGui PrepareI 
.text:64404F4F 
.text:64404F4F pvParam 
.text:64404F4F var 38 
.text:64404F4F var 34 
.text:64404F4F rc 
.text:64404F4F cy 
.text:64404F4F h 
.text:64404F4F var 14 
.text:64404F4F var 10 


nfoWindow proc near 


byte ptr -3Ch 
dword ptr -38h 
dword ptr -34h 
tagRECT ptr -2Ch 
dword ptr -1Ch 
dword ptr -18h 
dword ptr -14h 
dword ptr -10h 


.text:64404F4F var 4 dword ptr -4 

.text:64404F4F 

.text:64404F4F push 30h 

.text:64404F51 mov eax, offset loc 64438E00 

.text:64404F56 call . EH prolog3 

.text:64404F5B mov esi, ecx ; ECX is pointer to 
object 

.text:64404F5D xor ebx, ebx 

.text:64404F5F lea ecx, [ebp+var 14] 

.text:64404F62 mov [ebp+var 10], ebx 

; demangled name: ATL::CStringT(void) 

.text:64404F65 call ds:mfc90 316 

.text:64404F6B mov [ebp+var 4], ebx 

.text:64404F6E lea edi, [esi+2854h] 

.text:64404F74 push offset aEnvironmentInf ; 
"Environment information:\n" 

.text:64404F79 mov ecx, edi 


; demangled name: ATL::CStringT: 


.text:64404F7B C 
.text:64404F81 [e 
.text:64404F84 m 
.text:64404F8A j 
.text:64404F8C p 
.text:64404F8F l 
.text:64404F92 p 
"working directory: '%s'\n" 
.text:64404F97 p 


; demangled name: ATL::CStringT: 
.text:64404F98 c 


:operator=(char const *) 


all ds:mfc90 820 

mp [esi+38h], ebx 

ov ebx, ds:mfc90 2539 

be short loc_64404FA9 

ush dword ptr [esi+34h] 

ea eax, [ebp+var_14] 

ush offset aWorkingDirecto ; 
ush eax 


:Format(char const *,...) 
all ebx ; mfc90 2539 
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.text:64404F9A add 
.text:64404F9D lea 
.text:64404FA0 push 
.text:64404FA1 mov 


OCh 
[ebp+var_14] 


esp, 
eax, 
eax 
ecx, edi 


demangled name: ATL::CStringT::operator+=(class ATL::CSimpleStringT<char, 


.text:64404FA3 call 
.text:64404FA9 

.text:64404FA9 loc 64404FA9: 
.text:64404FA9 mov 
.text:64404FAC test 
.text:64404FAE jbe 
.text:64404FBO push 
.text:64404FB1 lea 
.text:64404FB4 push 


, 


"trace level %d activated\n" 


ds:mfc90 941 


eax, [esi+38h] 

eax, eax 

short loc 64404FD3 

eax 

eax, [ebp+var 14] 

offset aTraceLevelDAct ; 


. text: 64404FB9 push eax 

; demangled name: ATL::CStringT::Format(char const *,...) 
. text: 64404FBA call ebx ; mfc90 2539 

. text: 64404FBC add esp, OCh 

. text: 64404FBF lea eax, [ebp+var 14] 
.text:64404FC2 push eax 

.text:64404FC3 mov ecx, edi 


demangled name: ATL::CStringT::operator+=(class ATL::CSimpleStringT<char, 


.text:64404FC5 call 
.text:64404FCB xor 
.text:64404FCD inc 
.text:64404FCE mov 
.text:64404FD1 jmp 
. text: 64404FD3 
.text:64404FD3 loc 64404FD3: 
. text: 64404FD3 xor 
. text: 64404FD5 inc 
. text: 64404FD6 
.text:64404FD6 loc 64404FD6: 
.text:64404FD6 cmp 
.text:64404FD9 jbe 
.text:64404FDB cmp 
.text:64404FE2 jz 
.text:64404FEA4 ush 
"hexdump in trace activated An" 
.text:64404FE9 mov 


, 


.text:64404FEB call 
.text:64404FF1 

.text:64404FF1 loc 64404FF1: 
.text:64404FF1 

.text:64404FF1 cmp 
.text:64404FF5 jz 


ds:mfc90 941 

ebx, ebx 

ebx 

[ebp+var 10], ebx 
short loc 64404FD6 


ebx, ebx 
ebx 


[esi+38h], ebx 

short loc 64404FF1 

dword ptr [esi+2978h], O 
short loc_64404FF1 
offset aHexdumpInTrace ; 


ecx, edi 


; demangled name: ATL::CStringT::operator+=(char const *) 


ds:mfc90 945 


byte ptr [esi+78h], 0 
short loc 64405007 


1> const &) 


1> const 4) 
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.text:64404FF7 push 
"logging activated\n" 
.text:64404FFC mov 


, 


.text:64404FFE call 
.text:64405004 mov 
.text:64405007 

.text:64405007 loc 64405007: 
.text:64405007 cmp 
.text:6440500B jz 
.text:6440500D push 


"data compression switched off\n" 


. text: 64405012 mov 


, 


. text: 64405014 call 
.text:6440501A mov 
.text:6440501D 

.text:6440501D bypass: 
.text:6440501D mov 
.text:64405020 test 
.text:64405022 jz 
.text:64405024 cmp 
.text:64405028 jz 
.text:6440502A push 


"data record mode switched on\n" 


.text:6440502F mov 


, 


.text:64405031 call 
.text:64405037 mov 
.text:6440503A 

.text:6440503A loc 6440503A: 
.text:6440503A 

.text:6440503A mov 
.text:6440503C cmp 
.text:6440503F jnz 
.text:64405045 push 


, 


offset aLoggingActivat ; 


ecx, edi 


; demangled name: ATL::CStringT::operator+=(char const *) 


ds:mfc90 945 
[ebp+var 10], ebx 


byte ptr [esi+3Dh], 0 
short bypass 
offset aDataCompressio ; 


ecx, edi 


; demangled name: ATL::CStringT::operator+=(char const *) 


ds:mfc90 945 
[ebp+var 10], ebx 


eax, [esi+20h] 

eax, eax 

short loc 6440503A 
dword ptr [eax+28h], 0 
short loc_6440503A 
offset aDataRecordMode ; 


ecx, edi 


; demangled name: ATL::CStringT::operator+=(char const *) 


ds:mfc90_945 
[ebp+var_10], ebx 


ecx, edi 

[ebp+var_10], ebx 
loc_64405142 

offset aForMaximumData ; 


"\nFor maximum data security delete\nthe s"... 


. text: 6440504A call 
.text:64405050 xor 
.text:64405052 push 
.text:64405053 lea 
.text:64405056 push 
.text:64405057 push 
.text:64405058 push 
.text:6440505A call 
.text:64405060 mov 
.text:64405063 cmp 
.text:64405068 jte 


.text:6440506A cdq 


; demangled name: ATL::CStringT::operator+=(char const *) 


ds:mfc90 945 


edi, edi 

edi ; fWinIni 
eax, [ebp+pvParam] 

eax ; pvParam 
edi ; uiParam 
30h ; uiAction 


ds:SystemParametersInfoA 
eax, [ebp+var_34] 

eax, 1600 

short loc 64405072 
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text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:6440507A 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:644050B4 


.text 


.text: 
.text: 
.text: 
.text: 


; demangled name: ATL::CSimpleStringT:: 
.text: 
.text: 
.text: 


6440506B 
6440506D 
6440506F 
64405072 
64405072 
64405072 
64405073 


64405080 
64405083 
64405088 
6440508A 
64405090 
64405092 
64405098 
6440509E 
6440509F 
644050A2 
644050A4 
644050A8 
644050AC 
644050AF 


644050B7 
644050B8 
644050BE 
644050C1 


644050C8 
644050CE 
644050CF 


loc 64405072: 


call 
push 
lea 


eax, edx 
eax, 1 
[ebp+var 34], eax 


edi ; hWnd 
[ebp+cy], 0A0h 

ds :GetDC 
[ebp+var_10], eax 
ebx, 12Ch 

eax, edi 

loc_64405113 

11h rU 
ds :GetStockObject 
edi, ds:SelectObject 
eax Ph 
[ebp+var_10] ; hdc 
edi ; SelectObject 
[ebp+rc.left], 0 
[ebp+rc.top], 0 
[ebp+h], eax 


401h ; format 
eax, [ebp+rc] 
eax + prc 


ecx, [esi+2854h] 
[ebp+rc.right], ebx 
[ebp+rc.bottom], 0B4h 


GetLength(void) 

ds:mfc90 3178 

eax ; cchText 
ecx, [esi+2854h] 


; demangled name: const char* ATL::CSimpleStringT::operator PCXSTR 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
164405106 


.text 


.text: 
.text: 
.text: 
.text: 


644050D5 
644050DB 
644050DC 
644050DF 
644050E5 
644050E7 
644050ED 
644050F0 
644050F3 
644050F7 
644050FB 
644050FE 
64405100 
64405103 


64405108 
64405108 
64405108 
6440510B 


loc 64405108: 


call 
push 
push 
call 
push 
call 
mov 
sub 
cmp 
lea 
mov 
jz 
push 
push 
call 


push 
push 


ds:mfc90 910 


eax ; lpchText 
[ebp+var_10] ; hdc 
ds:DrawTextA 

4 ; nindex 


ds:GetSystemMetrics 
ecx, [ebp+rc.bottom] 
ecx, [ebp+rc.top] 
[ebp+h], 0 

eax, [eax+ecx+28h] 
[ebp+cy], eax 

short loc 6440510 
[ebp+h] ; h 
[ebp+var_10] ; hdc 
edi ; SelectObject 


[ebp+var_10] ; hDC 
0 ; hwnd 
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ds :ReleaseDC 


eax, [ebp+var_38] 


80h ; UFlags 
[ebp+cy] ; Cy 

eax 

ebx ; CX 

eax Y 


eax, [ebp+var 34] 
eax, OFFFFFED4h 


eax, edx 

eax, 1 

eax aX 

0 ; hwndInsertAfter 


dword ptr [esi+285Ch] ; hWnd 
ds:SetWindowPos 

ebx, ebx 

ebx 

short loc 6440514D 


offset byte 64443AF8 
ds:mfc90 820 


dword 6450B970, ebx 
short loc 64405188 

sub 6441C910 

dword 644F858C, ebx 
dword ptr [esi+2854h] 
offset aCdwsguiPrepare ; 


dword ptr [esi+2848h] 
dbg 

esp, OCh 

dword 644F858C, 2 
sub 6441C920 


[ebp+var_4], OFFFFFFFFh 
ecx, [ebp+var_14] 


ds:mfc90 601 
. EH epilog3 


.text:6440510D call 
.text:64405113 
.text:64405113 loc 64405113: 
.text:64405113 mov 
.text:64405116 push 
.text:6440511B push 
.text:6440511E inc 
.text:6440511F push 
.text:64405120 push 
.text:64405121 mov 
.text:64405124 add 
.text:64405129 cdq 
.text:6440512A sub 
.text:6440512C sar 
.text:6440512E push 
.text:6440512F push 
.text:64405131 push 
.text:64405137 call 
.text:6440513D xor 
.text:6440513F inc 
.text:64405140 jmp 
.text:64405142 
.text:64405142 loc 64405142: 
.text:64405142 push 
; demangled name: ATL::CStringT::operator=(char const *) 
.text:64405147 call 
.text:6440514D 
.text:6440514D loc 6440514D: 
.text:6440514D cmp 
.text:64405153 jl 
.text:64405155 call 
.text:6440515A mov 
.text:64405160 push 
.text:64405166 push 
"\nCDwsGui: :PrepareInfoWindow: sapgui env". 
.text:6440516B push 
.text:64405171 call 
.text:64405176 add 
.text:64405179 mov 
.text:64405183 call 
.text:64405188 
.text:64405188 loc 64405188: 
.text:64405188 or 
.text:6440518C lea 
; demangled name: ATL::CStringT:: CStringT() 
.text:6440518F call 
.text:64405195 call 
.text:6440519A retn 


.text:6440519A CDwsGui PrepareInfoWindow endp 


Au début de la fonction, ECX a un pointeur sur l'objet (puisque c'est une fonction avec 
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le type d'appel thiscall (3.21.1 on page 699)). Dans notre cas, l'objet a étonnement 
un type de classe de CDwsGui. En fonction de l'option mise dans l'objet, un message 
spécifique est concaténé au message résultant. 


Si la valeur à l'adresse this+0x3D n'est pas zéro, la compression est désactivée: 


.text:64405007 loc 64405007: 


.text:64405007 cmp byte ptr [esi+3Dh], 0 

. text :6440500B jz short bypass 

. text: 6440500D push offset aDataCompressio ; 
"data compression switched off\n" 

. text :64405012 mov ecx, edi 

; demangled name: ATL::CStringT::operator+=(char const *) 

. text: 64405014 call ds:mfc90 945 

.text:6440501A mov [ebp+var 10], ebx 


.text:6440501D 
.text:6440501D bypass: 


Finalement, il est intéressant de noter que l'état de la variable var 10 défini si le 
message est affiché: 


.text:6440503C cmp [ebp+var 10], ebx 
.text:6440503F jnz exit ; passe outre l'affichage 


; ajoute les chaînes "For maximum data security delete" / "the setting(s) as 
soon as possible !": 


.text:64405045 push offset aForMaximumData ; 
"\nFor maximum data security delete\nthe s"... 
.text:6440504A call ds:mfc90 945 ; 
ATL: :CStringT::operator+=(char const *) 
.text:64405050 xor edi, edi 
.text:64405052 push edi ; fWinIni 
.text:64405053 lea eax, [ebp+pvParam] 
.text:64405056 push eax ; pvParam 
.text:64405057 push edi ; uiParam 
.text:64405058 push 30h ; uiAction 
.text:6440505A call ds:SystemParametersInfoA 
.text:64405060 mov eax, [ebp+var 34] 
.text:64405063 cmp eax, 1600 
.text:64405068 jte short loc 64405072 
.text:6440506A cdq 
.text:6440506B sub eax, edx 
.text:6440506D sar eax, 1 
.text:6440506F mov [ebp+var 34], eax 


.text:64405072 
.text:64405072 loc 64405072: 


start drawing: 
.text:64405072 push edi ; hWnd 


. text :64405073 mov [ebp+cy], GAGh 
.text:6440507A call ds:GetDC 
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Vérifions notre théorie en pratique. 
JNZ à cette ligne ... 


.text:6440503F jnz exit ; passe outre l'affichage 


.. remplacons-le par un JMP, et nous obtenons SAPGUI fonctionnant sans que l'en- 
nuyeuse fenétre pop-up n'apparaisse! 


Maintenant approfondissons et trouvons la relation entre l'offset 0715 dans la fonction 
load command line() (nous lui avons donné ce nom) et la variable this+0x3D dans 
CDwsGui::PreparelnfoWindow. Sommes-nous sûrs que la valeur est la méme? 


Nous commençons par chercher toutes les occurrences de la valeur 0x15 dans le 
code. Pour un petit programme comme SAPGUI, cela fonctionne parfois.a Voici la 
première occurrence que nous obtenons: 


.text:64404C19 sub 64404C19 proc near 
.text:64404C19 


.text:64404C19 arg 0 - dword ptr 4 

.text:64404C19 

.text:64404C19 push ebx 

.text:64404C1A push ebp 

.text:64404C1B push esi 

.text:64404C1C push edi 

.text:64404C1D mov edi, [esp+10h+arg 0] 

.text:64404C21 mov eax, [edi] 

.text:64404C23 mov esi, ecx ; ESI/ECX sont des pointeurs 
sur un objet inconnu 

.text:64404C25 mov [esi], eax 

.text:64404C27 mov eax, [edi+4] 

.text:64404C2A mov [esi+4], eax 

.text:64404C2D mov eax, [edi+8] 

.text:64404C30 mov [esi+8], eax 

.text:64404C33 lea eax, [edi+0Ch] 

.text:64404C36 push eax 

.text:64404C37 lea ecx, [esi+0Ch] 

; demangled name:  ATL::CStringT::operator-(class ATL::CStringT ... &) 

.text:64404C3A call ds:mfc90 817 

.text:64404C40 mov eax, [edi+10h] 

. text :64404C43 mov [esi+10h], eax 

.text:64404C46 mov al, [edi+14h] 

.text:64404C49 mov [esi+14h], al 

.text:64404C4C mov al, [edi+15h] ; cope l'octet de 
l' offset 0x15 

.text:64404C4F mov [esi+15h], al ; dans l'offset 0x15 de 


l'objet CDwsGui 


La fonction a été appelée depuis la fonction appelée CDwsGui::CopyOptions ! Encore 
merci pour les informations de débogage. 


Mais la vraie réponse est dans CDwsGul::Init() : 


1153 


.text:6440BOBF loc 6440BO0BF: 

.text:6440BOBF mov eax, [ebp+arg 0] 

. text: 6440B0C2 push [ebp+arg_ 4] 

. text: 6440B0C5 mov [esi+2844h], eax 

. text: 6440B0CB lea eax, [esi+28h] ; ESI est un pointeur 
sur L'objet CDwsGui 

. text: 6440B0CE push eax 

.text:6440BOCF call CDwsGui  CopyOptions 


Enfin, nous comprennons: le tableau rempli dans la fonction load command line() 
est stocké dans la classe CDwsGui mais à l'adresse this+0x28. 0x15 + 0x28 vaut 
exactement 0x3D. OK, nous avons trouvé le point où la valeur y est copiée. 


Trouvons les autres endroits oü l'offset Ox3D est utilisé. Voici l'un d'entre eux dans 
la fonction CDwsGui::SapguiRun (à nouveau, merci aux appels de débogage) : 


.text:64409D58 cmp [esi+3Dh], bl ; ESI est un pointeur 
sur l'objet CDwsGui 

.text:64409D5B lea ecx, [esi+2B8h] 

.text:64409D61 setz al 

.text:64409D64 push eax ; arg 10 de 
CConnectionContext: :CreateNetwork 

.text:64409D65 push dword ptr [esi+64h] 

; nom original: const char* ATL::CSimpleStringT::operator PCXSTR 

.text:64409D68 call ds:mfc90 910 

.text:64409D68 ; pas d'arguments 

.text:64409D6E push eax 

.text:64409D6F lea ecx, [esi+2BCh] 

; nom orignal: const char* ATL::CSimpleStringT::operator PCXSTR 

.text:64409D75 call ds:mfc90 910 

.text:64409D75 ; pas d'arguments 

.text:64409D7B push eax 

.text:64409D7C push esi 

.text:64409D7D lea ecx, [esi+8] 

.text:64409D80 call CConnectionContext  CreateNetwork 


Vérifions nos découvertes. 

Remplacons setz al par les instructions xor eax, eax / nop, effacons la variable 
d'environnement TDW NOCOMPRESS et lançons SAPGUI. Ouah! La fenêtre ennuyeuse 
n'est plus là (Comme nous l'attendions, puisque la variable d'environnement n'est 
pas mise) mais dans Wireshark nous pouvons voir que les paquets réseau ne sont 
plus compressés! Visiblement, c'est le point oü le flag de compression doit étre défini 
dans l'objet CConnectionContext. 


Donc, le flag de compression est passé dans le 5éme argument de CConnectionCon- 
text::CreateNetwork. A l'intérieur de la fonction, une autre est appelée: 


.text:64403476 push [ebp+compression] 
.text:64403479 push [ebp«arg C] 
.text:6440347C push [ebp+arg_8] 
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.text:6440347F push [ebp+arg_4] 
. text: 64403482 push [ebp+arg_ 0] 
. text: 64403485 call CNetwork__CNetwork 


Le flag de compression est passé ici dans le 5éme argument au constructer CNet- 
work::CNetwork. 


Et voici comment le constructeur CNetwork défini le flag dans l'objet CNetwork sui- 
vant son 5éme argument et une autre variable qui peut probablement aussi affecter 
la compression des paquets réseau. 


.text:64411DF1 cmp [ebp+compression], esi 

.text:64411DF7 jz short set EAX to 0 

.text:64411DF9 mov al, [ebx+78h] ; une autre valeur 
pourrait affecter la compression? 

.text:64411DFC cmp al, '3' 

.text:64411DFE jz short set_EAX to 1 

. text: 64411E00 cmp al, '4' 

. text: 64411E02 jnz short set EAX to 0 


.text:64411E04 
.text:64411E04 set EAX to 1: 


.text:64411bE04 xor eax, eax 
.text:64411E06 inc eax ; EAX -> 1 
.text:64411E07 jmp short loc 64411E0B 


.text:64411E09 

.text:64411bE09 set EAX to 0: 

.text:64411E09 

.text:64411E09 xor eax, eax ; EAX -> 0 

.text:64411E0B 

.text:64411bE0B loc 64411E0B: 

.text:64411E0B mov [ebx+3A4h], eax ; EBX est un pointeur 
sur l'object CNetwork 


À ce point, nous savons que le flag de compression est stocké dans la classe CNet- 
work à l'adresse this+0x3A4. 


Plongeons-nous maintenant dans SAPguilib.dll à la recherche de la valeur 0x3A4. Et il 
yaune seconde occurrence dans CDwsGui::OnClientMessageWrite (Merci infiniment 
pour les informations de débogage) : 


.text:64406F76 loc 64406F76: 


.text:64406F76 mov ecx, [ebp+7728h+var 7794] 
.text:64406F79 cmp dword ptr [ecx+3A4h], 1 
.text:64406F80 jnz compression flag is zero 
.text:64406F86 mov byte ptr [ebx+7], 1 
.text:64406F8A mov eax, [esi+18h] 
.text:64406F8D mov ecx, eax 

.text:64406F8F test eax, eax 

.text:64406F91 ja short loc 64406FFF 
.text:64406F93 mov ecx, [esi+14h] 
.text:64406F96 mov eax, [esi+20h] 


.text:64406F99 
.text:64406F99 loc 64406F99: 
.text:64406F99 push dword ptr [edi+2868h] ; int 
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.text:64406F9F lea edx, [ebp+7728h+var_77A4] 

. text :64406FA2 push edx ; int 

. text: 64406FA3 push 30000 rt 

.text:64406FA8 lea edx, [ebp+7728h+Dst] 

. text :64406FAB push edx ; Dst 

. text: 64406FAC push ecx ; int 

.text:64406FAD push eax SFE 

. text: 64406FAE push dword ptr [edi+28C0h] ; int 

.text:64406FB4 call sub_644055C5 ; routine de 
compression actuelle 

.text:64406FB9 add esp, 1Ch 

.text:64406FBC cmp eax, OFFFFFFF6h 

.text:64406FBF jz short loc 64407004 

.text:64406FC1 cmp eax, 1l 

. text: 64406FC4 jz loc 6440708C 

.text:64406FCA cmp eax, 2 

.text:64406FCD jz short loc 64407004 

.text:64406FCF push eax 

.text:64406FD0 push offset aCompressionErr ; 
"compression error [rc = %d]- program wi"... 

.text:64406FD5 push offset aGui err compre ; 
"GUI ERR COMPRESS" 

.text:64406FDA push dword ptr [edi+28D0h] 

.text:64406FE0 call SapPcTxtRead 


Jetons un œil dans sub 644055C5. Nous y voyons seulement l'appel à memcpy() et 
une autre fonction appelée (par IDA) sub 64417440. 


Et, regardons dans sub 64417440. Nous y voyons: 


.text:6441747C push offset aErrorCsrcompre ; 
"\nERROR: CsRCompress: invalid handle" 

.text:64417481 call eax ; dword 644F94C8 

.text:64417483 add esp, 4 


Voilà! Nous avons trouvé la fonction qui effectue la compression des données. Comme 
cela a été décrit dans le passé *°, 


cette fonction est utilisé dans SAP et aussi dans le projet open-source MaxDB. Donc, 
elle est disponible sous forme de code source. 


La derniére vérification est faite ici: 


.text:64406F79 cmp dword ptr [ecx+3A4h], 1 
.text:64406F80 jnz compression flag is zero 


Remplacons ici JNZ par un JMP inconditionnel. Supprimons la variable d'environne- 
ment TDW NOCOMPRESS. Voilà! 


Dans Wireshark nous voyons que les messages du client ne sont pas compressés. 
Les réponses du serveur, toutefois, le sont. 


Donc nous avons trouvé le lien entre la variable d'environnement et le point oü la 
routine de compression peut étre appelée ou non. 


35http://conus.info/utils/SAP pkt decompr.txt 
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8.12.2 Fonctions de vérification de mot de passe de SAP 6.0 


Lorsque je suis retourné sur SAP 6.0 IDES installé sur une machine VMware, je me 
suis apercu que j'avais oublié le mot de passe pour le compte SAP*, puis je m'en 
suis souvenu, mais j'ai alors eu ce message «Password logon no longer possible - 
too many failed attempts», car j'ai fait trop de tentatives avant de m'en rappeler. 


La premiére trés bonne nouvelle füt que le fichier PDB complet de disp+work.pdb 
était fourni avec SAP, et il contient presque tout: noms de fonction, structures, types, 
variable locale et nom d'arguments, etc. Quel cadeau somptueux! 


Il y a l'utilitaire TYPEINFODUMP?Ó pour convertir les fichiers PDB en quelque chose 
de lisible et grepable. 


Voici un exemple d'information d'une fonction + ses arguments + ses variables lo- 
cales: 


FUNCTION ThVmcSysEvent 


Address: 10143190 Size: 675 bytes Index: 60483 Vv 
S TypeIndex: 60484 
Type: int NEAR C ThVmcSysEvent (unsigned int, unsigned char, unsigned > 
y short*) 
Flags: 0 
PARAMETER events 
Address: Reg335+288 Size: 4 bytes Index: 60488 Typelndex: 2 
y 60489 
Type: unsigned int 
Flags: do 
PARAMETER opcode 
Address: Reg335+296 Size: 1 bytes Index: 60490 Typelndex: ? 
y 60491 
Type: unsigned char 
Flags: do 
PARAMETER serverName 
Address: Reg335+304 Size: 8 bytes Index: 60492 Typelndex: Y 
Y 60493 
Type: unsigned short* 
Flags: do 
STATIC_LOCAL VAR func 
Address: 12274af0 Size: 8 bytes Index: 60495 z? 


S Typelndex: 60496 
Type: wchar t* 
Flags: 80 
LOCAL VAR admhead 
Address: Reg335+304 Size: 8 bytes Index: 60498 Typelndex: ? 
Y 60499 
Type: unsigned char* 
Flags: 90 
LOCAL VAR record 
Address: Reg335+64 Size: 204 bytes Index: 60501 TypeIndex: ? 
y 60502 
Type: AD RECORD 
Flags: 90 


36http://www.debuginfo.com/tools/typeinfodump.html 
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LOCAL_VAR adlen 
Address: Reg335+296 Size: 4 bytes Index: 60508 TypeIndex: ? 
V 60509 
Type: int 
Flags: 90 


Et voici un exemple d'une structure: 


STRUCT DBSL STMTID 
Size: 120 Variables: 4 Functions: O Base classes: O 
MEMBER moduletype 

Type: DBSL MODULETYPE 

Offset: 0 Index: 3 TypeIndex: 38653 
MEMBER module 

Type: wchar t module[40] 


Offset: 4 Index: 3 TypeIndex: 831 
MEMBER stmtnum 

Type: long 

Offset: 84 Index: 3 TypeIndex: 440 


MEMBER timestamp 
Type: wchar t timestamp[15] 
Offset: 88 Index: 3 TypeIndex: 6612 


Wow! 


Une autre bonne nouvelle: les appels de debugging (il y en a beaucoup) sont trés 
utiles. 


Ici, vous pouvez remarquer la variable globale ct level? , qui reflète le niveau actuel 
de trace. 


Il y a beaucoup d'ajout de débogage dans le fichier diso+work.exe : 


cmp cs:ct level, 1 

jl short loc_1400375DA 

call DpLock 

lea rcx, aDpxxtool4_c ; "dpxxtool4.c" 

mov edx, 4Eh ; line 

call CTrcSaveLocation 

mov r8, cs:func 48 

mov rcx, cs:hdl ; hdl 

lea rdx, aSDpreadmemvalu ; "%s: DpReadMemValue (%d)" 
mov r9d, ebx 


call DpTrcErr 
call DpUnlock 


Si le niveau courant de trace est plus élevé ou égal à la limite défini dans le code ici, 
un message de débogage est écrit dans les fichiers de log comme dev w0, dev disp, 
et autres fichiers dev*. 


Essayons de grepper dans le fichier que nous avons obtenu à l'aide de l'utilitaire 
TYPEINFODUMP: 


37Plus d'information sur le niveau de trace: http://help.sap.com/saphelp_nwpi71/helpdata/en/46/ 
962416a5a613e8e10000000a155369/content.htm 
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cat "disp+work.pdb.d" | grep FUNCTION | grep -i password 


Nous obtenons: 


FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 
FUNCTION 


rcui::AgiPassword: :DiagISelection 

ssf password encrypt 

ssf password decrypt 

password logon disabled 
dySignSkipUserPassword 

migrate password history 

password is initial 
rcui::AgiPassword::IsVisible 

password distance ok 

get password downwards compatibility 
dySignUnSkipUserPassword 

rcui::AgiPassword: :GetTypeName 

" rcui::AgiPassword::AgiPassword':: 1'::dtor$2 
"rcui::AgiPassword::AgiPassword':: 1'::dtor$0 
"rcui::AgiPassword::AgiPassword':: 1'::dtor$1 
usm set password 

rcui::AgiPassword::TraceTo 

days since last password change 

rsecgrp generate random password 
rcui::AgiPassword:: scalar deleting destructor' 
password attempt limit exceeded 

handle incorrect password 
"rcui::AgiPassword:: scalar deleting destructor''::°1'::dtor$1 
calculate new password hash 

shift password to history 

rcui::AgiPassword: :GetType 

found password in history 
"rcui::AgiPassword:: scalar deleting destructor'':: 1'::dtor$0 
rcui::Agi0bj::IsaPassword 

password idle check 

SlicHwPasswordForDay 

rcui::AgiPassword: :IsaPassword 
rcui::AgiPassword: :AgiPassword 
delete user password 

usm set user password 

Password API 

get password change for SSO 

password in USR40 

rsec agrp abap generate random password 


Essayons aussi de chercher des messages de debug qui contiennent les mots «pass- 
word» et «locked». L'un d'entre eux se trouve dans la chaíne «user was locked by 
subsequently failed password logon attempts», référencé dans 

la fonction password attempt limit exceeded(). 


D'autres chaínes que cette fonction peut écrire dans le fichier de log sont: «password 
logon attempt will be rejected immediately (preventing dictionary attacks)», «failed- 
logon lock: expired (but not removed due to 'read-only' operation)», «failed-logon 
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lock: expired => removed». 


Aprés avoir joué un moment avec cette fonction, nous remarquons que le probléme 
se situe exactement dedans. Elle est appelée depuis la fonction chckpass() —une 
des fonctions de vérification u mot de passe. 


d'abord, nous voulons étre sürs que nous sommes au bon endroit: 


Lancons tracer : 


tracer64.exe -a:disp+work.exe bpf=disp+work.exe!chckpass,args:3,unicode 


PID=2236 | TID=2248| (0) disp+work.exe!chckpass (0x202c770, L"Breweredl 2 
S ", 0x41) (called from 0x1402f1060 (disp+work. ? 
y exelusrexist+0x3c0)) 

PID-2236|TID-2248|(0) disp+work.exe!chckpass -> 0x35 


L'enchainement des appels est: syssigni() -> DylSigni() -> dychkusr() -> usrexist() 
-> chckpass(). 


Le nombre 0x35 est une erreur renvoyée dans chckpass() á cet endroit: 


.text:00000001402ED567 loc_1402ED567: ; CODE XREF: 
chckpass+B4 


.text:00000001402ED567 mov rcx, rbx ; usr02 
.text:00000001402ED56A call password idle check 
.text:00000001402ED56F cmp eax, 33h 
.text:00000001402ED572 jz loc 1402EDB4E 
.text:00000001402ED578 cmp eax, 36h 
.text:00000001402ED57B jz loc 1402EDB3D 
.text:00000001402ED581 xor edx, edx ; 
usr02 readonly 
.text:00000001402ED583 mov rcx, rbx ; usr02 
.text:00000001402ED586 call 2 
\ password attempt limit exceeded 
.text:00000001402ED58B test al, al 
.text:00000001402ED58D jz short loc 1402ED5A0 
.text:00000001402ED58F mov eax, 35h 
.text:00000001402ED594 add rsp, 60h 
.text:00000001402ED598 pop r14 
. text: 00000001402ED59A pop r12 
. text: 00000001402ED59C pop rdi 
.text:00000001402ED59D pop rsi 
.text:00000001402ED59E pop rbx 
.text:00000001402ED59F retn 


Bien, vérifions: 


tracer64.exe -a:disp+work.exe bpfzdisp*work.exe!7 
S password attempt limit exceeded,args:4,unicode,rt:0 


PID=2744|TID=360|(0) disp+work.exe!password attempt limit exceeded (07 


Y x202c770, 0, 0x257758, 0) 


 chckpass+0xeb)) 


(called from 0x1402ed58b (disp+work.exe! 7 
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PID=2744|TID=360|(0) disp+work.exe! password attempt limit exceeded -> 1 
PID=2744|TID=360|We modify return value (EAX/RAX) of this function to 0 
PID=2744|TID=360|(0) disp+work.exe!password attempt limit exceeded (07 
V x202c770, 0, 0, 0) (called from 0x1402e9794 (disp+work.exe!chngpass+0 
y xe4)) 
PID=2744|TID=360|(0) disptwork.exe! password attempt limit exceeded -> 1 
PID=2744|TID=360|We modify return value (EAX/RAX) of this function to 0 


Excellent! Nous pouvons nous connecter avec succés maintenant. 


À propos, nous pouvons prétendre que nous avons oublier le mot de passe, modi- 
fier la fonction chckpass() afin qu'elle renvoie toujours une valeur de 0, ce qui est 
suffisant pour passer outre la vérification: 


tracer64.exe -a:disp+work.exe bpf=disp+work.exe!chckpass,args:3,unicode, rt / 


S :0 
PID-2744|TID-360|(0) disp+work.exe!chckpass (0x202c770, L"bogus 2 
G ", 0x41) (called from 0x1402f1060 (disp+work.v 


V exel!lusrexist+0x3c0)) 
PID=2744|TID=360|(0) disp+work.exe!chckpass -> 0x35 
PID=2744|TID=360|We modify return value (EAX/RAX) of this function to 0 


Ce que l'on peut aussi dire en analysant la fonction 
password attempt limit exceeded(), c'est qu'à son tout début, on voit cet appel: 


lea rcx, aLoginFailed us ; "login/failed user auto unlock" 
call sapgparam 

test rax, rax 

jz short loc 1402E19DE 
movzx eax, word ptr [rax] 
cmp ax, 'N' 

jz short loc 1402E19D4 
cmp ax, 'n' 

jz short loc 1402E19D4 
cmp ax, '0' 

jnz short loc 1402E19DE 


Étonnement, la fonction sapgparam() est utilisée pour chercher la valeur de certains 
paramétres de configuration. Cette fonction peut étre appelée depuis 1768 endroits 
différents. Il semble qu'avec l'aide de cette information, nous pouvons facilement 
trouver les endroits dans le code, oü le contróle du flux est affecté par des configu- 
rations spécifiques de paramétres. 


C'est vraiment agréable. Le nom des fonctions est trés clair, bien plus que dans 
Oracle RDBMS. Il semble que le processus disp+work est écrit en C++. A-t-il été 
récrit il y a quelques temps? 
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8.13 Oracle RDBMS 
8.13.1 Table V$VERSION dans Oracle RDBMS 


Oracle RDBMS 11.2 est un programme gigantesque, son module principal oracle.exe 
contient environ 124000 fonctions. Par comparaison, le noyau de Windows 7 x86 
(ntoskrnl.exe) contient environ 11000 fonctions et le noyau Linux 3.9.8 (avec les 
drivers par défaut compilés)—31000 fonctions. 


Commencons par une question facile. OU Oracle RDBMS trouve-t-il toutes ces infor- 
mations, lorsque l'on exécute une expression simple dans SQL*Plus: 


SQL» select * from V$VERSION; 


Et nous obtenons: 


BANNER 


Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production 
PL/SQL Release 11.2.0.1.0 - Production 

CORE 11.2.0.1.0 Production 

TNS for 32-bit Windows: Version 11.2.0.1.0 - Production 

NLSRTL Version 11.2.0.1.0 - Production 


Allons-y. OU Oracle RDBMS trouve-t-il la chaine V$VERSION ? 


Dans la version win32, le fichier oracle.exe contient la chaîne, c'est facile a voir. 
Mais nous pouvons aussi utiliser les fichiers objet (.o) de la version Linux d'Oracle 
RDBMS, puisque contrairement a la version win32 oracle.exe, les noms de fonc- 
tions (et aussi les variables globales) y sont préservés. 


Donc, le fichier kqf .o contient la chaîne V$VERSION. Le fichier objet se trouve dans 
la bibliothéque Oracle principale libserverll.a. 


On trouve une référence à ce texte dans la table kqfviw stockée dans le méme 
fichier, kqf.o: 


Listing 8.10 : kgf.o 


.rodata:0800C4A0 kqfviw dd 0Bh ; DATA XREF: kqfchk:loc 8003A6D 
.rodata :0800C4A0 ; kqfgbn+34 

.rodata:0800C4A4 dd offset 2 STRING 10102 0 ; "GVSWAITSTAT" 
.rodata:0800C4A8 dd 4 

.rodata:0800C4AC dd offset 2 STRING 10103 0 ; "NULL" 
.rodata:0800C4B0 dd 3 

.rodata:0800C4B4 dd 0 

.rodata:0800C4B8 dd 195h 

.rodata:0800C4BC dd 4 

.rodata:0800C4CO dd 0 

.rodata:0800C4C4 dd OFFFFC1CBh 

.rodata:0800C4C8 dd 3 

.rodata:0800C4CC dd 0 

.rodata:0800C4DO dd 0Ah 
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.Fodata:0800C4D4 dd offset 2 STRING 10104 0 ; "V$WAITSTAT" 
.Fodata:0800C4D8 dd 4 

.rodata:0800C4DC dd offset 2 STRING 10103 0 ; "NULL" 
.rodata:0800C4E0 dd 3 

.rodata:0800C4E4 dd 0 

.Fodata:0800C4E8 dd 4Eh 

.rodata:0800C4EC dd 3 

.rodata:0800C4F0 dd 0 

.rodata:0800C4F4 dd OFFFFCOO3h 

.Fodata:0800C4F8 dd 4 

.rodata:0800C4FC dd 0 

.rodata:0800C500 dd 5 

.rodata:0800C504 dd offset 2 STRING 10105 0 ; "GV$BH" 
.rodata:0800C508 dd 4 

.rodata:0800C50C dd offset 2 STRING 10103 0 ; "NULL" 
.rodata:0800C510 dd 3 

.rodata:0800C514 dd 0 

.rodata:0800C518 dd 269h 

.rodata:0800C51C dd 15h 

.rodata:0800C520 dd 0 

.rodata:0800C524 dd OFFFFCIEDh 

.rodata:0800C528 dd 8 

.rodata:0800C52C dd 0 

.rodata:0800C530 dd 4 

.rodata:0800C534 dd offset 2 STRING 10106 0 ; "V$BH" 
.rodata:0800C538 dd 4 

.rodata:0800C53C dd offset 2 STRING 10103 0 ; "NULL" 
.rodata:0800C540 dd 3 

.rodata:0800C544 dd 0 

.rodata:0800C548 dd OF5h 

.rodata:0800C54C dd 14h 

.rodata:0800C550 dd 0 

.rodata:0800C554 dd OFFFFCIEEh 

.rodata:0800C558 dd 5 

.rodata:0800C55C dd 0 


À propos, souvent, en analysant les entrailles dOracle RDBMS, vous pouvez vous 
demander pourquoi les noms de fonctions et de variables globales sont si étranges. 


Sans doute parce qu'Oracle RDBMS est un trés vieux produit et a été développé en 
C dans les années 80. 


Et c'était un temps oü le standard C garantissait que les noms de fonction et de va- 
riable pouvaient supporter seulement jusqu'à 6 caractéres incluant: «6 charactéres 
significatifs dans un identifiant externe»?? 


Probablement que la table kqfviw contient la plupart (peut-étre méme toutes) des 
vues préfixées avec V$, qui sont des vues fixées, toujours présentes. Superficielle- 
ment, en remarquant la récurrence cyclique des données, nous pouvons facilement 
voir que chaque élément de la table kqfviw a 12 champs de 32-bit. C'est trés facile 
de créer une structure de 12 éléments dans IDA et de l'appliquer à tous les éléments 


38Draft ANSI C Standard (ANSI X3J11/88-090) (May 13, 1988) (yurichev.com) 
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de la table. Depuis Oracle RDBMS version 11.2, il y a 1023 éléments dans la table, 
¡.e., dans celle-ci sont décrites 1023 de toutes les vues fixées possible. 


Nous reviendrons à ce nombre plus tard. 


Comme on le voit, il n'y a pas beaucoup d'information sur les nombres dans les 
champs. Le premier nombre est toujours égal au nom de la vue (sans le zéro de fin). 


Nous savons aussi que l'information sur toutes ces vues fixes peut étre récupérée 
depuis une vue fixée appelée V$FIXED VIEW DEFINITION (à propos, l'information 
pour cette vue est aussi prise dans les tables kqfviw et kqfvip.) Au fait, il y a aussi 
1023 éléments dans celle-ci. Coincidence? Non. 


SQL> select * from V$FIXED VIEW DEFINITION where view name-'V$VERSION'; 


VIEW NAME 


V$VERSION 
select BANNER from GV$VERSION where inst id - USERENV('Instance') 


Donc, V$VERSION est une sorte de vue terminale pour une autre vue appelée GV$VERSION, 
qui est, à son tour: 


SQL> select * from V$FIXED VIEW DEFINITION where view name-'GV$VERSION'; 


VIEW NAME 


GV$VERSION 
select inst_id, banner from x$version 


Les tables préfixées par X$ dans Oracle RDBMS sont aussi des tables de service, 
non documentées, qui ne peuvent pas étre modifiées par l'utilisateur et qui sont 
rafraíchies dynamiquement. 


Si nous cherchons le texte 


select BANNER from GV$VERSION where inst id - 
USERENV (Instance) 


… dans le fichier kqf.o, nous le trouvons dans la table kqfvip : 


Listing 8.11 : kqf.o 


.rodata:080185A0 kqfvip dd offset 2 STRING 11126 0 ; DATA XREF: kqfgven+18 
.rodata:080185A0 ; kqfgvt+F 
. rodata:080185A0 ; 
"select inst id, decode(indx,1,'data bloc"... 
| .rodata:080185A4 dd offset kqfv459 c 0 
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.rodata:080185A8 dd 0 

.rodata:080185AC dd 0 

. rodata: 08019570 dd offset 2 STRING 11378 0 ; 
"select BANNER from GV$VERSION where in"... 

. rodata:08019574 dd offset kqfv133 c 0 

. rodata: 08019578 dd 0 

. rodata:0801957C dd 0 

. rodata: 08019580 dd offset 2 STRING 11379 0 ; 
"select inst id,decode(bitand(cfflg,1),0"... 

.rodata:08019584 dd offset kqfv403 c 0 

. rodata: 08019588 dd 0 

. rodata:0801958C dd 0 

. rodata: 08019590 dd offset 2 STRING 11380 0 ; 
"select STATUS , NAME, IS RECOVERY DEST"... 

. rodata: 08019594 dd offset kqfv199 c 0 


La table semble avoir 4 champs dans chaque élément. A propos, elle a 1023 élé- 
ments, encore, le nombre que nous connaissons déja. 


Le second champ pointe sur une autre table qui contient les champs de la table pour 
cette vue fixée. Comme pour V$VERSION, cette table a seulement deux éléments, le 
premier est 6 et le second est la chaine BANNER (le nombre 6 est la longueur de la 
chaine) et aprés, un élément de fin qui contient O et une chaine C null : 


Listing 8.12 : kqf.o 


.rodata:080BBAC4 kqfv133 c 0 dd 6 ; DATA XREF: .rodata:08019574 
.rodata:080BBAC8 dd offset 2 STRING 5017 0 ; "BANNER" 
.rodata:080BBACC dd 0 

. rodata:080BBADO dd offset 2 STRING 0 0 


En joignant les données des deux tables kqfviw et kqfvip, nous pouvons obtenir la 
déclaration SQL qui est exécutée lorsque l'utilisateur souhaite faire une requéte sur 
une vue fixée spécifique. 


Ainsi nous pouvons écrire un programme oracle tables??, pour collecter toutes ces 
informations d'un fichier objet d'Oracle RDBMS pour Linux. 


Listing 8.13 : Résultat de oracle tables 


kqfviw element.viewname: [V$VERSION] ?: 0x3 0x43 0x1 Oxffffc085 0x4 

kqfvip element.statement: [select BANNER from GV$VERSION where inst id = 7 
S USERENV('Instance')] 

kqfvip element.params: 

[BANNER] 


Et: 


Listing 8.14 : Résultat de oracle tables 
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kqfviw element.viewname: [GV$VERSION] ?: 0x3 0x26 0x2 Oxffffc192 0x1 
kqfvip element.statement: [select inst id, banner from x$version] 
kqfvip element.params: 

[INST ID] [BANNER] 


La vue fixée GV$VERSION est différente de V$VERSION seulement parce qu'elle a un 
champ de plus avec l'identifiant de l'instance. 


Quoiqu'il en soit, nous allons rester avec la table X$VERSION. Tout comme les autres 
tables X$, elle n'est pas documentée, toutefois, nous pouvons y effectuer des re- 
quétes: 


SQL» select * from x$version; 


ADDR INDX INST ID 
BANNER 
ODBAF574 0 1 


Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production 


Cette table a des champs additionnels, comme ADDR et INDX. 


En faisant défiler kqf .o dans IDA, nous pouvons repérer une autre table qui contient 
un pointeur sur la chaine X$VERSION, c'est kqftab : 


Listing 8.15 : kqf.o 


.Fodata:0803CACO dd 9 ; element number Ox1f6 
.rodata:0803CAC4 dd offset 2 STRING 13113 0 ; "X$VERSION" 
.rodata:0803CAC8 dd 4 

.rodata:0803CACC dd offset 2 STRING 13114 0 ; "kqvt" 
.rodata:0803CADO dd 4 

.rodata:0803CAD4 dd 4 

.rodata:0803CAD8 dd 0 

.rodata:0803CADC dd 4 

.rodata :0803CAE0 dd OCh 

.rodata:0803CAE4 dd OFFFFCO75h 

.rodata:0803CAE8 dd 3 

.rodata:0803CAEC dd 0 

.rodata:0803CAFO dd 7 

.Fodata:0803CAF4 dd offset 2 STRING 13115 0 ; "X$KQFSZ" 
.rodata:0803CAF8 dd 5 

.rodata:0803CAFC dd offset 2 STRING 13116 0 ; "kqfsz" 
.rodata:0803CB00 dd 1 

.rodata:0803CB04 dd 38h 

.rodata:0803CB08 dd 0 

.rodata:0803CBOC dd 7 

.rodata:0803CB10 dd 0 

.rodata:0803CB14 dd OFFFFCO9Dh 


.Fodata:0803CB18 dd 2 
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.rodata :0803CB1C dd 0 | 


Il y a beaucoup de référence aux noms de X$-table, visiblement, à toutes les X$- 
tables d'Oracle RDBMS 11.2. Mais encore une fois, nous n'avons pas assez d'infor- 
mation. 


Ce que signifie la chaine kqvt n'est pas clair. 
Le préfixe kq peut signifier kernel ou query. 
v signifie apparemment version et t—type ? Difficile a dire. 


Une table avec un nom similaire se trouve dans kqf.o: 


Listing 8.16 : kqf.o 


.rodata:0808C360 kqvt c 0 kqftap param «4, offset 2 STRING 19 0, 917h, 0,7 
0,0, 4, 0, 0> 

.rodata:0808C360 ; DATA XREF: 
.rodata:08042680 

. rodata:0808C360 ; "ADDR" 

.rodata:0808C384 kqftap param «4, offset 2 STRING 20 0, 0B02h, 2 
0, 0, 0, 4, 0, 0» ; 

.rodata:0808C3A8 kqftap param «7, offset 2 STRING 21 0, 0B02h, 2 
& 0, 0, 0, 4, 0, 0> ; 
"INST ID" 

.rodata:0808C3CC kqftap param <6, offset 2 STRING 5017 0, 601h, 2 
& 0, 0, 0, 50h, 0, © ; 

.rodata:0808C3FO kqftap param «0, offset 2 STRING 0 0, 0, 0, 0, 7 
& 0, 0, 0, © 


Elle contient des informations à propos de tous les champs de la table X$VERSION. 
La seule référence à cette table est dans la table kqftap : 


Listing 8.17 : kgf.o 


. rodata: 08042680 kqftap element «0, offset kqvt c 0, offset” 
Y kqvrow, 0» ; element 0x1f6 


Il est intéressant de voir que cet élément ici est Ox1f6th (502nd), tout comme le 
pointeur sur la chaine X$VERSION dans la table kqftab. 


Sans doute que les tables kqftap et kqftab sont complémentaires l'une de l'autre, 
tout comme kqfvip et kqfviw. 


Nous voyons aussi un pointeur sur la fonction kqvrow(). Enfin, nous obtenons quelque 
chose d'utile! 


Nous ajoutons donc ces tables à notre utilitaire oracle tables^?. Pour X$VERSION nous 
obtenons: 


Listing 8.18 : Résultat de oracle tables 


kqftab element.name: [X$VERSION] ?: [kqvt] 0x4 0x4 0x4 Oxc Oxffffc075 0x3 
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kqftap param.name-[ADDR] ?: 0x917 0x0 0x0 0x0 0x4 0x0 0x0 
kqftap param.name-[INDX] ?: 0xb02 0x0 0x0 0x0 0x4 0x0 0x0 
kqftap param.name-[INST ID] ?: 0xb02 0x0 0x0 0x0 0x4 0x0 0x0 
kqftap param.name-[BANNER] ?: 0x601 0x0 0x0 0x0 0x50 0x0 0x0 
kqftap element.fnl-kqvrow 

kqftap element.fn2-NULL 


Avec l'aide de tracer, il est facile de vérifier que cette fonction est appelée 6 fois 
par ligne (depuis la fonction qerfxFetch()) lorsque l'on fait une requête sur la table 


X$VERSION. 


Lancons tracer en mode cc (il commente chaque instruction exécutée) : 


tracer -a:oracle.exe bpf=oracle.exe! kqvrow,trace:cc 


_kqvrow_ proc near 


var 7C - byte ptr -7Ch 
var 18 - dword ptr -18h 
var 14 - dword ptr -14h 
Dest - dword ptr -10h 
var C = dword ptr -OCh 
var 8 - dword ptr -8 

var 4 - dword ptr -4 

arg 8 = dword ptr 10h 
arg C = dword ptr 14h 
arg_14 = dword ptr 1Ch 
arg_18 = dword ptr 20h 


; FUNCTION CHUNK AT .text1:056C11A0 SIZE 00000049 BYTES 


push ebp 

mov ebp, esp 

sub esp, 7Ch 

mov eax, [ebp+arg 14] ; [EBP+1Ch]=1 

mov ecx, TlsIndex ; [69AEBO8h]=0 

mov edx, large fs:2Ch 

mov edx, [edx+ecx*4] ; [EDX+ECX*4]=0xc98c938 
cmp eax, 2 ; EAX=1 

mov eax, [ebptarg 8] ; [EBP+10h]=0xcdfe554 
jz loc 2CE1288 

mov ecx, [eax] ; [EAX]=0..5 

mov [ebp+var_4], edi ; EDI-0xc98c938 


loc 2CE10F6: ; CODE XREF: _kqvrow +10A 
; _kqvrow_+1A9 


cmp ecx, 5 ; ECX=0..5 

ja loc 56C11C7 

mov edi, [ebp+arg_18] ; [EBP+20h]=0 
mov [ebp+var 14], edx ; EDX=0xc98c938 
mov [ebp+var 8], ebx ; EBX=0 

mov ebx, eax ; EAX=0xcdfe554 


mov [ebp+var_C], esi ; ESI=0xcdfe248 
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loc 2CE110D: ; CODE XREF: _kqvrow +29E00E6 


mov edx, ds:off 628B09C[ecx*4] ; [ECX*4+628B09Ch]=0x2ce1116, 
Ox2cellac, Ox2celldb, Ox2cellf6, 0x2ce1236, 0x2ce127a 
jmp edx ; EDX=0x2ce1116, Ox2cellac, Ox2celldb, 


Ox2cellf6, 0x2ce1236, 0x2ce127a 


loc 2CE1116: ; DATA XREF: .rdata:off 628B09C 
push offset aXKqvvsnBuffer ; "x$kqvvsn buffer" 


mov ecx, [ebp+arg C] ; [EBP+14h]=0x8a172b4 
xor edx, edx 

mov esi, [ebp+var_14] ; [EBP-14h]=0xc98c938 
push edx ; EDX=0 

push edx ; EDX=0 

push 50h 

push ecx ; ECX=0x8a172b4 


push dword ptr [esi+10494h] ; [ESI+10494h]=0xc98cd58 


call . kghalf ; tracing nested maximum level (1) reached, 
skipping this CALL 

mov esi, ds: imp vsnnum ; [59771A8h]-0x61bc49e0 

mov [ebp+Dest], eax ; EAX=0xce2ffb0 

mov [ebx+8], eax ; EAX=0xce2ffb0 

mov [ebx+4], eax ; EAX=0xce2ffb0 

mov edi, [esi] ; [ESI]=0xb200100 

mov esi, ds: imp vsnstr ; [597D6D4h]=0x65852148, "- 
Production” 

push esi ; ESI=0x65852148, "- Production" 

mov ebx, edi ; EDI=0xb200100 

shr ebx, 18h ; EBX=0xb200100 

mov ecx, edi ; EDI=0xb200100 

shr ecx, 14h ; ECX=0xb200100 

and ecx, OFh ; ECX=0xb2 

mov edx, edi ; EDI=0xb200100 

shr edx, OCh ; EDX=0xb200100 

movzx edx, dl ; DL-0 

mov eax, edi ; EDI=0xb200100 

shr eax, 8 ; EAX=0xb200100 

and eax, OFh ; EAX=0xb2001 

and edi, OFFh ; EDI=0xb200100 

push edi ; EDI-0 

mov edi, [ebp+arg 18] ; [EBP+20h]=0 

push eax ; EAX=1 

mov eax, ds: imp vsnban ; 
[597D6D8h]=0x65852100, "Oracle Database 11g Enterprise Edition Release %d.%d.%d.%d. 

push edx ; EDX=0 

push ecx ; ECX=2 

push ebx ; EBX=0xb 

mov ebx, [ebp+arg 8] ; [EBP+10h]=0xcdfe554 

push eax i 
EAX=0x65852100, "Oracle Database 11g Enterprise Edition Release %d.%d.%d. 

mov eax, [ebp+Dest] ; [EBP-10h]=0xce2ffb0 

push eax ; EAX=0xce2ffb0 


call ds: imp sprintf ; opl1-MSVCR80.dll!sprintf tracing nested 
maximum level (1) reached, skipping this CALL 
add esp, 38h 


% 


d 


% 


g” 
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mov dword ptr [ebx], 1 


loc 2CE1192: ; CODE XREF: _kqvrow_+FB 
; _kqvrow_+128 ... 


test edi, edi ; EDI=0 

jnz . VInfreq kqvrow 

mov esi, [ebp+var C] ; [EBP-0Ch]=0xcdfe248 

mov edi, [ebp+var 4] ; [EBP-4]=0xc98c938 

mov eax, ebx ; EBX=0xcdfe554 

mov ebx, [ebp+var_8] ; [EBP-8]=0 

lea eax, [eax+4] ; [EAX+4]=0xce2ffb0, "NLSRTL Version 
11.2.0.1.0 - Production", "Oracle Database 11g Enterprise Edition Release 


11.2.0.1.0 - Production", "PL/SQL Release 11.2.0.1.0 - Production", "TNS 
for 32-bit Windows: Version 11.2.0.1.0 - Production" 


loc 2CE11A8: ; CODE XREF: kqvrow +29E00F6 


mov esp, ebp 

pop ebp 

retn ; EAX=0xcdfe558 

loc 2CE11AC: ; DATA XREF: .rdata:0628B0A0 

mov edx, [ebx+8] ; [EBX+8]=0xce2ffb0, "Oracle Database 11g 
Enterprise Edition Release 11.2.0.1.0 - Production" 

mov dword ptr [ebx], 2 

mov [ebx+4], edx ; EDX=0xce2ffb0, "Oracle Database 11g 
Enterprise Edition Release 11.2.0.1.0 - Production" 

push edx ; EDX=0xce2ffb0, "Oracle Database 11g 
Enterprise Edition Release 11.2.0.1.0 - Production" 

call _kkxvsn ; tracing nested maximum level (1) reached, 
skipping this CALL 

pop ecx 

mov edx, [ebx+4] ; [EBX+4]=0xce2ffb0, "PL/SOL Release 


11.2.0.1.0 - Production” 
MOVZX ecx, byte ptr [edx] ; [EDX]=0x50 


test ecx, ecx ; ECX=0x50 

jnz short loc 2CE1192 

mov edx, [ebp+var_14] 

mov esi, [ebp+var_C] 

mov eax, ebx 

mov ebx, [ebp+var_8] 

mov ecx, [eax] 

jmp loc 2CE10F6 

loc 2CE11DB: ; DATA XREF: .rdata:0628B0A4 

push 0 

push 50h 

mov edx, [ebx+8] ; [EBX+8]=0xce2ffb0, "PL/SOL Release 
11.2.0.1.0 - Production" 

mov [ebx+4], edx ; EDX=0xce2ffb0, "PL/SQL Release 11.2.0.1.0 
- Production" 

push edx ; EDX=0xce2ffb0, "PL/SQL Release 11.2.0.1.0 
- Production" 

_Imxver ; tracing nested maximum level (1) reached, 

skipping this CALL 

add esp, OCh 

mov dword ptr [ebx], 3 


jmp short loc 2CE1192 
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loc_2CE11F6: ; DATA XREF: .rdata:0628B0A8 


mov edx, [ebx+8] ; [EBX+8]=0xce2ffb0 

mov [ebp+var_18], 50h 

mov [ebx+4], edx ; EDX=0xce2ffb0 

push 0 

call  npinli ; tracing nested maximum level (1) reached, 
skipping this CALL 

pop ecx 

test eax, eax ; EAX=0 

jnz loc 56C11DA 

mov ecx, [ebp+var 14] ; [EBP-14h]=0xc98c938 

lea edx, [ebp+var_18] ; [EBP-18h]=0x50 

push edx ; EDX=0xd76c93c 


push dword ptr [ebx+8] ; [EBX+8]=0xce2ffb0 
push dword ptr [ecx+13278h] ; [ECX+13278h]=0xaccel90 


call _nrtnsvrs ; tracing nested maximum level (1) reached, 
skipping this CALL 
add esp, OCh 
loc 2CE122B: ; CODE XREF: _kqvrow +29E0118 
mov dword ptr [ebx], 4 
jmp loc 2CE1192 
loc 2CE1236: ; DATA XREF: .rdata:0628B0AC 
lea edx, [ebp+var 7C] ; [EBP-7Ch]=1 
push edx ; EDX=0xd76c8d8 
push 0 
mov esi, [ebx+8] ; [EBX+8]=0xce2ffb0, "TNS for 32-bit 
Windows: Version 11.2.0.1.0 - Production" 
mov [ebx+4], esi ; ESI=0xce2ffb0, "TNS for 32-bit Windows: 
Version 11.2.0.1.0 - Production" 
mov ecx, 
mov [ebp+var_18], ecx ; ECX=0x50 
push ecx ; ECX=0x50 
push esi ; ESI=0xce2ffb0, "TNS for 32-bit Windows: 
Version 11.2.0.1.0 - Production" 
call _lxvers ; tracing nested maximum level (1) reached, 
skipping this CALL 
add esp, 10h 
mov edx, [ebp+var_18] ; [EBP-18h]=0x50 
mov dword ptr [ebx], 5 
test edx, edx ; EDX=0x50 
jnz loc 2CE1192 
mov edx, [ebp+var_14] 
mov esi, [ebp+var_C] 
mov eax, ebx 
mov ebx, [ebp+var_8] 
mov ecx, 5 
jmp loc 2CE10F6 
loc 2CE127A: ; DATA XREF: .rdata:0628B0B0 
mov edx, [ebp+var_14] ; [EBP-14h]=0xc98c938 
mov esi, [ebp+var C] ; [EBP-0Ch]=0xcdfe248 


mov edi, [ebp+var_4] ; [EBP-4]=0xc98c938 
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mov eax, ebx ; EBX=0xcdfe554 
mov ebx, [ebp+var_8] ; [EBP-8]=0 
loc 2CE1288: ; CODE XREF: _kqvrow_+1F 

mov eax, [eax+8] ; [EAX+8]=0xce2ffb0, "NLSRTL Version 
11.2.0.1.0 - Production" : 

test eax, eax ; EAX=0xce2ffb0, "NLSRTL Version 11.2.0.1.0 
- Production” 

jz short loc 2CE12A7 

push offset aXKqvvsnBuffer ; "x$kqvvsn buffer" 

push eax ; EAX=0xce2ffb0, "NLSRTL Version 11.2.0.1.0 
- Production" 

mov eax, [ebptarg C] ; [EBP+14h]=0x8a172b4 

push eax ; EAX-0x8a172b4 

push dword ptr [edx+10494h] ; [EDX+10494h]=0xc98cd58 

call _kghf rf ; tracing nested maximum level (1) reached, 
skipping this CALL 

add esp, 10h 


loc 2CE12A7: ; CODE XREF: _kqvrow +1C1 


xor eax, eax 
mov esp, ebp 

pop ebp 

retn ; EAX-0 


 kqvrow  endp 


Maintenant, il est facile de voir que le nombre est passé de l'extérieur. La fonction 
renvoie une chaíne, construite comme ceci: 


String 1 | Using vsnstr, vsnnum, vsnban global variables. 
Calls sprintf(). 

String 2 | Calls kkxvsn(). 

String 3 | Calls lmxver(). 

String 4 | Calls npinli(), nrtnsvrs(). 

String 5 | Calls lxvers(). 


C'est ainsi que les fonctions correspondantes sont appelées pour déterminer la ver- 
sion de chaque module. 


8.13.2 Table X$KSMLRU dans Oracle RDBMS 


Il y a une mention d'une table spéciale dans la note Diagnosing and Resolving Error 
ORA-04031 on the Shared Pool or Other Memory Pools [Video] [ID 146599.1] : 


Il y a une table fixée appelée X$KSMLRU qui suit les différentes 
allocations dans le pool partagé qui force les autres objets du pool 
partagé à vieillir. Cette table fixée peut étre utilisée pour identifier ce 
qui cause une grosse allocation. 

Si plusieurs objets sont supprimés périodiquement du pool partagé, 
alors ceci va poser des problémes de temps de réponse et va probable- 
ment provoquer des problémes de contention du verrou de cache de 
bibliothéque lorsque les objets seront rechargés dans le pool partagé. 
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Une chose inhabituelle à propos de la table fixée X$KSMLRU est que 
le contenu de la table fixée est écrasé à chaque fois que quelqu'uni ef- 
fectue requéte dans la table fixée. Ceci est fait puisque la table fixée 
ne contient que l'allocation la plus large qui s'est produite. Les valeurs 
sont réinitialisées aprés avoir été sélectionnées, de sorte que les allo- 
cations importantes suivantes puissent éte inscrites, méme si elles ne 
sont pas aussi laarges que celles qui se sont produites précédemment. 
À cause de cette réinitialisation, la sortie produite par la sélection de 
cette table doit étre soigneusement conservée puisqu'elle ne peut plus 
étre récupérée aprés que la requéte a été faite. 


Toutefois, comme on peut le vérifier facilement, le contenu de cette table est effacé à 
chaque fois qu'on l'interroge. Pouvons-nous trouver pourquoi? Retournons aux tables 
que nous connaissons déjà: kqftab et kqftap qui sont générées avec l'aide d'oracle 
tables^!, qui a toutes les informations concernant les table X$-. Nous pouvons voir 
ici que la fonction ksmlrs() est appelée pour préparer les éléments de cette table: 


Listing 8.19 : Résultat de oracle tables 


kqftab element.name: 
kqftap param.name-[ADDR] ?: 
kqftap param.name-[INDX] ?: 
kqftap param.name-[INST ID] ?: 
kqftap param.name-[KSMLRIDX] ?: 


[X$KSMLRU] ?: [ksmlr] 0x4 0x64 0x11 Oxc OxffffcObb 0x5 
0x917 0x0 0x0 0x0 0x4 0x0 0x0 

0xb02 0x0 0x0 0x0 0x4 0x0 0x0 

0xb02 0x0 0x0 0x0 0x4 0x0 0x0 

0xb02 0x0 0x0 0x0 0x4 0x0 0x0 


kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 
kqftap_ param. 


name=[KSMLRDUR] ?: 


name= [KSMLRSHRPOOL ] ?: 


name=[KSMLRCOM] 
name=[KSMLRSIZ] 
name=[KSMLRNUM] 
name=[KSMLRHON] 
name=[KSMLROHV] 
name=[KSMLRSES] 
name=[KSMLRADU] 
name=[KSMLRNID] 
name=[KSMLRNSD] 
name=[KSMLRNCD] 
name=[KSMLRNED] 


kqftap element.fnl-ksmlrs 
kqftap element.fn2-NULL 


?: 


NUNN NN NN NN © 


0xb02 0x0 0x0 0x0 0x4 0x4 0x0 
0xb02 0x0 0x0 0x0 0x4 0x8 0x0 
0x501 0x0 0x0 0x0 Ox14 Oxc 0x0 


: 0x2 0x0 0x0 0x0 0x4 0x20 0x0 

: 0x2 0x0 0x0 0x0 0x4 0x24 0x0 

: 0x501 0x0 0x0 0x0 0x20 0x28 0x0 
: 0xb02 0x0 0x0 0x0 0x4 0x48 0x0 
: 0x17 0x0 0x0 0x0 0x4 Ox4c 0x0 

: 0x2 0x0 0x0 0x0 0x4 0x50 0x0 

: 0x2 0x0 0x0 0x0 0x4 0x54 0x0 

: 0x2 0x0 0x0 0x0 0x4 0x58 0x0 

: 0x2 0x0 0x0 0x0 0x4 Ox5c 0x0 

: 0x2 0x0 0x0 0x0 0x4 0x60 0x0 


En effet, avec l'aide de tracer, il est facile de voir que cette fonction est appelée à 
chaque fois que nous interrogeons la table X$KSMLRU. 


Ici nous voyons une référence aux fonctions ksmsplu sp() et ksmsplu jp(), cha- 
cune d'elles appelle ksmsplu() á la fin. Ala fin de la fonction ksmsplu() nous voyons 
un appel a memset() : 


Listing 8.20 : ksm.o 
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.text:00434C50 loc 434C50: ; DATA XREF: .rdata:off 5E50EA8 
.text:00434C50 mov edx, [ebp-4] 
.text:00434C53 mov [eax], esi 
.text:00434C55 mov esi, [edi] 
.text:00434C57 mov [eax+4], esi 
.text:00434C5A mov [edi], eax 
.text:00434C5C add edx, 1 

.text:00434C5F mov [ebp-4], edx 
.text:00434C62 jnz loc 434B7D 
.text:00434C68 mov ecx, [ebp+14h] 
.text:00434C6B mov ebx, [ebp-10h] 
.text:00434C6E mov esi, [ebp-0Ch] 
.text:00434C71 mov edi, [ebp-8] 
.text:00434C74 lea eax, [ecx+8Ch] 
.text:00434C7A push 370h ; Size 
.text:00434C7F push 0 ; Val 
.text:00434C81 push eax ; Dst 
.text:00434C82 call _ intel fast memset 
.text:00434C87 add esp, OCh 
.text:00434C8A mov esp, ebp 

. text: 00434C8C pop ebp 

. text: 00434C8D retn 


.text:00434C8D ksmsplu endp 


Des constructions comme memset (block, 0, size) sont souvent utilisées pour 
mettre a zéro un bloc de mémoire. Que se passe-t-il si nous prenons le risque de 
bloquer l'appel a memset (block, 0, size) et regardons ce qui se produit? 


Lancons tracer avec les options suivantes: mettre un point d'arrét en 0x434C7A (le 
point où les arguments sont passés a memset ( )), afin que tracer mette le compteur 
de programme EIP au point oü les arguments passés à memset() sont éffacés (en 
0x434C8A). On peut dire que nous simulons juste un saut inconditionnel de l'adresse 
0x434C7A a 0x434C8A. 


tracer -a:oracle.exe bpx=oracle.exe!0x00434C7A, set (eip, 0x00434C8A) 


(Important: toutes ces adresses sont valides seulement pour la version win32 de 
Oracle RDBMS 11.2) 


En effet, nous pouvons maintenant interroger la table X$KSMLRU autant de fois que 
nous voulons et elle n’est plus du tout effacée! 


Au cas ou, n'essayez pas ceci sur vos serveurs de production. 


Ce n'est probablement pas un comportement trés utile ou souhaité, mais comme 
une expérience pour déterminer l'emplacement d'un bout de code dont nous avons 
besoin, ca remplit parfaitement notre besoin! 


8.13.3 Table V$TIMER dans Oracle RDBMS 


V$TIMER est une autre vue fixée qui refléte une valeur changeant rapidement: 
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V$TIMER affiche le temps écoulé en centiémes de seconde. Le 
temps est mesuré depuis le début de the epoch, qui est dépendant du 
système d'exploitation, et qui redevient O si la valeur déborde quatre 
Octets (environ 497 jours). 


(From Oracle RDBMS documentation ^?) 


Il est intéressant que les périodes soient différentes pour Oracle pour win32 et pour 
Linux. Allons-nous réussir à trouver la fonction qui génére cette valeur? 


On voit que cette valeur est finalement prise de la table X$KSUTM. 


SQL> select * from V$FIXED VIEW DEFINITION where view_name='V$TIMER' ; 


VIEW NAME 


V$TIMER 
select HSECS from GV$TIMER where inst id = USERENV('Instance') 


SQL> select * from V$FIXED VIEW DEFINITION where view name-'GV$TIMER'; 


VIEW NAME 


GV$TIMER 
select inst id,ksutmtim from x$ksutm 


Nous maintenant bloqué par un petit probléme, il n'y a pas de référence à une ou 
des fonction(s) générants des valeurs dans les tables kqftab/kqftap : 


Listing 8.21 : Résultat de oracle tables 


kqftab element.name: [X$KSUTM] ?: [ksutm] 0x1 0x4 0x4 0x0 OxffffcO9b 0x3 
kqftap param.name-[ADDR] ?: 0x10917 0x0 0x0 0x0 0x4 0x0 0x0 

kqftap param.name-[INDX] ?: 0x20b02 0x0 0x0 0x0 0x4 0x0 0x0 

kqftap param.name-[INST ID] ?: 0xb02 0x0 0x0 0x0 0x4 0x0 0x0 

kqftap param.name-[KSUTMTIM] ?: 0x1302 0x0 0x0 0x0 0x4 0x0 Oxle 

kqftap_ element. fn1=NULL 

kqftap element. fn2=NULL 


Lorsque nous essayons de trouver la chaine KSUTMTIM, nous la voyons dans cette 
fonction: 


kqfd DRN ksutm c proc near ; DATA XREF: .rodata:0805B4E8 


^?http://docs.oracle.com/cd/B28359 01/server.111/b28320/dynviews 3104.htm 
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arg 0 = dword ptr 8 
arg 8 = dword ptr 10h 
arg C - dword ptr 14h 
push ebp 
mov ebp, esp 


push [ebp+arg_C] 

push offset ksugtm 

push offset 2 STRING 1263 0 ; "KSUTMTIM" 
push [ebp+arg_8] 

push [ebp+arg_0] 

call kgfd cfui drain 


add esp, 14h 
mov esp, ebp 
pop ebp 

retn 


kqfd DRN ksutm c endp 


La fonction kqfd DRN ksutm c() est mentionnée dans la 
table kqfd tab registry 0: 


dd offset 2 STRING 62 0 ; "X$KSUTM" 
dd offset kqfd OPN ksutm c 

dd offset kqfd tabl fetch 

dd 0 

dd 0 

dd offset kqfd DRN ksutm c 


Il y a une fonction ksugtm() référencée ici. Voyons ce qu'elle contient dans (Linux 
x86) : 


Listing 8.22 : ksu.o 


ksugtm proc near 


var_1C = byte ptr -1Ch 
arg 4 = dword ptr OCh 
push ebp 
mov ebp, esp 
sub esp, 1Ch 
lea eax, [ebp+var_1C] 
push eax 
call slgcs 
pop ecx 
mov edx, [ebp+arg 4] 
mov [edx], eax 
mov eax, 4 
mov esp, ebp 
pop ebp 
retn 


ksugtm  endp 
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Le code dans la version win32 est presque le méme. 


Est-ce la fonction que nous cherchons? Regardons: 


tracer -a:oracle.exe bpf=oracle.exe! ksugtm,args:2,dump_args:0x4 


Essayons encore: 


SQL> select * from V$TIMER; 
27294929 

SQL» select * from V$TIMER; 
27295006 

SQL» select * from V$TIMER; 


27295167 


Listing 8.23 : Sortie de tracer 


TID=2428|(0) oracle.exe! ksugtm (0x0, Oxd76c5f0) (called from oracle.exe!7 
S  VInfreq gerfxFetch+0xfad (0x56bb6d5)) 

Argument 2/2 

0D76C5F0: 38 C9 "8. 2 
S " 

TID=2428|(0) oracle.exe! ksugtm () -» 0x4 (0x4) 

Argument 2/2 difference 

00000000: D1 7C AO 01 d e 2 
S " 

TID=2428|(0) oracle.exe! ksugtm (0x0, Oxd76c5f0) (called from oracle.exe! 7 
S — VInfreq gerfxFetch+0xfad (0x56bb6d5)) 

Argument 2/2 

0D76C5F0: 38 C9 "B. 2 
(ee " 

TID=2428|(0) oracle.exe! ksugtm () -» 0x4 (0x4) 

Argument 2/2 difference 

00000000: 1E 7D AO 01 a ed e 2 
S " 

TID=2428|(0) oracle.exe! ksugtm (0x0, Oxd76c5f0) (called from oracle.exe!7 
S  VInfreq gerfxFetch+0xfad (0x56bb6d5)) 

Argument 2/2 

0D76C5F0: 38 C9 "8. 2 
S LL 

TID=2428| (0) oracle.exe! ksugtm () -> 0x4 (0x4) 

Argument 2/2 difference 

00000000: BF 7D AO 01 ET 2 
tS " 
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En effet—la valeur est la méme que celle que nous voyons dans SQL*Plus et elle est 
renvoyée dans le second argument. 


Regardons ce que slgcs() contient (Linux x86) : 


slgcs proc near 


var 4 = dword ptr -4 
arg 0 = dword ptr 8 
push ebp 
mov ebp, esp 
push esi 
mov [ebp+var 4], ebx 
mov eax, [ebp+arg 0] 
call $+5 
pop ebx 
nop ; PIC mode 
mov ebx, offset GLOBAL OFFSET TABLE 
mov dword ptr [eax], 0 
call sltrgatime64 ; PIC mode 
push 0 
push OAh 
push edx 
push eax 
call __udivdi3 ; PIC mode 
mov ebx, [ebp+var 4] 
add esp, 10h 
mov esp, ebp 
POP ebp 
retn 
slgcs  endp 


(c'est simplement un appel à sltrgatime64() 


et la division de son résultat par 10 (3.12 on page 636)) 


Et la version win32: 


_slgcs proc near ; CODE XREF: dbgefgHtElResetCount+15 
; dbgerRunActions+1528 
db 66h 
nop 
push ebp 
mov ebp, esp 
mov eax, [ebp+8] 
mov dword ptr [eax], 0 
call ds: imp GetTickCountQO ; GetTickCount() 
mov edx, eax 
mov eax, OCCCCCCCDh 
mul edx 
shr edx, 3 
mov eax, edx 
mov esp, ebp 
pop ebp 
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retn 
_slgcs endp 


I| s'agit simplement du résultat de GetTickCount () ® divisé par 10 (3.12 on page 636). 


Voila! C'est pourquoi la version win32 et Linux x86 montrent des résultats différents, 
car ils sont générés par des fonctions de l'OS différentes. 


Drain implique apparemment de connecter une colonne de table spécifique à une 
fonction spécifique. 


Nous allons ajouter le support de la table kqfd tab registry 0 à oracle tables^^, 
maintenant nous voyons comment les variables des colonnes de table sont connec- 
tée à une fonction spécifique: 


[X$KSUTM] [kqfd OPN ksutm c] [kqfd tabl fetch] [NULL] [NULL] [7 
V kqfd DRN ksutm c] 

[X$KSUSGIF] [kqfd OPN ksusg c] [kqfd tabl fetch] [NULL] [NULL] [2 
V kqfd DRN ksusg c] 


OPN, signifie apparemment open, et DRN, apparemment drain. 


8.14 Code assembleur écrit à la main 


8.14.1 Fichier test EICAR 


Ce fichier .COM est destiné à tester les logiciels anti-virus, il est possible de le lancer 
sous MS-DOS et il affiche cette chaine: «EICAR-STANDARD-ANTIVIRUS-TEST-FILE! » 
45 


Une de ses propriété importante est qu'il est entiérement composé de symboles 
ASCII affichables, qui, de fait, permet de le créer dans n'importe quel éditeur de 
texte: 


X50! P%@AP [ANPZX54 (P^) 7CC) 7} $EICAR- STANDARD - ANTIVIRUS - TEST - FILE ! $H+H* 


Décompilons-le: 


; conditions initiales: SP=0FFFEh, SS:[SP]=0 


0100 58 pop ax 

; AX-0, SP-0 

0101 35 4F 21 xor ax, 214Fh 

; AX = 214Fh et SP = 0 

0104 50 push ax 

; AX = 214Fh, SP = FFFEh et SS:[FFFE] = 214Fh 
0105 25 40 41 and ax, 4140h 

; AX = 140h, SP = FFFEh et SS:[FFFE] = 214Fh 
0108 50 push ax 


; AX = 140h, SP = FFFCh, SS:[FFFC] = 140h et SS:[FFFE] = 214Fh 


43MSDN 
^^yurichev.com 
^5Wikipédia 
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0109 5B pop bx 

; AX = 140h, BX = 140h, SP = FFFEh et SS:[FFFE] = 214Fh 

010A 34 5C xor al, 5Ch 

; AX = 11Ch, BX = 140h, SP = FFFEh et SS:[FFFE] = 214Fh 

010C 50 push ax 

010D 5A pop dx 

; AX = 11Ch, BX = 140h, DX = 11Ch, SP = FFFEh et SS:[FFFE] = 214Fh 
010E 58 pop ax 

; AX = 214Fh, BX = 140h, DX = 11Ch et SP = 0 

010F 35 34 28 xor ax, 2834h 

; AX = 97Bh, BX = 140h, DX = 11Ch et SP = 0 

0112 50 push ax 

0113 5E pop si 

; AX = 97Bh, BX = 140h, DX = 11Ch, SI = 97Bh et SP = 0 

0114 29 37 sub [bx], si 

0116 43 inc bx 

0117 43 inc bx 

0118 29 37 sub [bx], si 

011A 7D 24 jge short near ptr word 10140 

011C 45 49 43 ... db 'EICAR-STANDARD - ANTIVIRUS-TEST-FILE!$' 
0140 48 2B word 10140 dw 2B48h ; CD 21 (INT 21) sera ici 
0142 48 2A dw 2A48h ; CD 20 (INT 20) sera ici 
0144 0D db ODh 

0145 0A db OAh 


J'ai ajouté des commentaires à propos des registres et de la pile après chaque ins- 
truction. 


En gros, toutes ces instructions sont là seulement pour exécuter ce code: 


B4 09 MOV AH, 9 

BA 1C 01 MOV DX, 11Ch 
CD 21 INT 21h 

CD 20 INT 20h 


INT 21h avec la 9ème fonction (passée dans AH) affiche simplement une chaîne, 
dont l'adresse est passée dans DS:DX. À propos, la chaîne doit être terminée par le 
signe '$'. Apparemment, c'est hérité de CP/M et cette fonction a été laissée dans 
DOS pour la compatibilité. INT 20h renvoie au DOS. 


Mais comme on peut le voir, l'opcode de cette instruction n'est pas strictement affi- 
chable. Donc, la partie principale du fichier EICAR est: 


* prépare les valeurs du registre dont nous avons besoin (AH et DX); 
* prépare les opcodes INT 21 et INT 20 en mémoire; 
* exécute INT 21 et INT 20. 


À propos, cette technique est largement utilisée dans la construction de shellcode, 
lorsque l'on doit passer le code x86 sous la forme d'une chaine. 


Voici aussi une liste de toutes les instructions x86 qui ont des opcodes affichables: 
.1.6 on page 1345. 
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8.15 Démos 


Les démos (ou démonstrations?) étaient un excellent moyen de s'éxercer en mathé- 
matiques, programmation graphique et code x86 pointu. 


8.15.1 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 


Tous les exemples sont des fichier MS-DOS .COM. 


Dans [Nick Montfort et al, 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, (The MIT 
Press:2012)] 46 


nous pouvons nous renseigner sur l'un des générateurs de labyrinthe le plus simple 
possible. 


Il affiche simplement un caractère slash ou backslash aléatoirement et indéfiniment, 
donnant quelque chose comme ceci: 


Il y a quelques implémentations connues en x86 16-bit. 


Version de Trixter en 42 octets 


Le listing provient du site web^/, mais les commentaires sont miens. 


00000000: B001 mov al,1 ; mettre le mode vidéo 40x25 
00000002: CD10 int 010 
00000004: 30FF xor bh,bh ; mettre la page vidéo pour 


l'appel int 10h 


^6 Aussi disponible en http://trope-tank.mit.edu/10 PRINT 121114.pdf 
^"http://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ 


1181 


00000006: B9D007 mov cx,007D0 ; 2000 caractères sur la 

00000009: 31C0 xor ax,ax 

0000000B: 9C pushf ; pousser les flags 

; prendre une valeur aléatoire du chip timer 

0000000C: FA cli ; interdire les interruptions 

0000000D: E643 out 043,al ; écrire O sur le port 43h 

; lire une valeur 16-bit depuis le port 40h 

0000000F: E440 in al,040 

00000011: 88C4 mov ah,al 

00000013: E440 in al,040 

00000015: 9D popf ; autoriser les interruptions 
en restaurant le flag IF 

00000016: 86C4 xchg ah,al 

; ici nous avons une valeur 16-bit pseudo-aléatoire 

00000018: D1E8 shr ax,1 

0000001A: D1E8 shr ax,1 

; CF contient le second bit de la valeur 

0000001C: BO5C mov al,05C ;'* 

; Si CF=1, sauter l'instruction suivante 

0000001E: 7202 jc 000000022 

; si CF=0, recharger le registre AL avec un autre caractére 

00000020: BO2F mov al,02F ;'/' 

; caractére de sortie 

00000022: B40E mov ah,00E 

00000024: CD10 int 010 

00000026: E2E1 loop 000000009 ; boucler 2000 fois 

00000028: CD20 int 020 ; Sortir dans le DOS 


La valeur pseudo aléatoire ici est en fait le temps qui a passé depuis le démarrage 
du systéme, pris depuis le temps du chip 8253, dont la valeur est incrémentée 18,2 
fois par seconde. 


En écrivant zéro sur le port 43h, nous envoyons la commande «select counter 0 », 
"counter latch", "binary counter" (pas une valeur BCD). 


Les interruptions sont ré-autorisées avec l'instruction POPF, qui restaure aussi le flag 
IF. 


Il n'est pas possible d'utiliser l'instruction IN avec des registres autres que AL, d'oü 
le mélange. 


Ma tentative de réduire la version de Trixter: 27 octets 


Nous pouvons dire que puisque nous utilisons le timer non pas pour avoir une valeur 
précise, mais une valeur pseudo aléatoire, nous n'avons pas besoin de passer du 
temps (et du code) pour interdire les interruptions. 


Une autre chose que l'on peut dire est que nous n'avons besoin que d'un bit de la 
partie basse 8-bit, donc lisons-le seulement. 


Nous pouvons réduire légérement le code et obtenons 27 octets: 


00000000: B9D007 mov cx,007D0 ; limiter la sortie à 2000 caractères 
00000003: 31C0 xor ax,ax ; commande pour le chip timer 
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00000005: E643 out 043,al 

00000007: E440 in al,040 ; lire 8-bit du timer 
00000009: D1E8 shr ax,1 ; mettre le second bit dans le flag CF 
0000000B: D1E8 shr ax,1 

0000000D: B05C mov al,05C ; préparer '\' 
0000000F: 7202 jc 000000013 

00000011: BO2F mov al,02F ; préparer '/' 

; output character to screen 

00000013: B40E mov ah, 00E 

00000015: CD10 int 010 

00000017: E2EA loop 000000003 

; exit to DOS 

00000019: CD20 int 020 


Prendre le contenu résiduel de la mémoire comme source d'aléas 


Puisqu'il s'agit de MS-DOS, il n'y a pas du tout de protection de la mémoire, nous 
pouvons lire l'adresse que nous voulons. Encore mieux que ca: une seule instruction 
LODSB lit un octet depuis l'adresse DS: SI, mais ce n'est pas un probléme si les valeurs 
des registres ne sont pas définies, lisons 1) des octets aléatoires; 2) depuis un endroit 
aléatoire de la mémoire! 


Il est suggéré dans la page web de Trixter**d'utiliser LODSB sans aucune initialisation. 


Il est aussi suggéré que l'on utilisé à la place l'instruction SCASB, car elle met les 
flags suivant l'octet qu'elle lit. 


Une autre idée pour minimiser le code est d'utiliser l'appel systéme DOS INT 29h, 
qui affiche simplement le caractére stocké dans le registre AL. 


C'est ce que Peter Ferrie a fait ^? : 


Listing 8.24 : Peter Ferrie: 10 octets 


; AL est aléatoire à ce point 

00000000: AE scasb 

; CF est mis suivant le résultat de la soustraction 
; de l'octet aléatoire de la mémoire de AL. 

; donc c'est quelque peu aléatoire ici 


00000001: D6 setalc 

; AL est mis à OxFF si CF=1 ou à 0 autrement 

00000002: 242D and al,02D ;'-' 

; AL vaut ici 0x2D ou 0 

00000004: 042F add al,02F ;'/' 

; AL vaut ici 0x5C ou 0x2F 

00000006: CD29 int 029 ; afficher AL sur l'écran 
00000008: EBF6 jmps 000000000 ; boucler indéfiniment 


Donc il est possible de se passer complétement de saut conditionnel. Le code ASCII 
du backslash («1») est 0x5C et 0x2F pour le slash («/ »). Dons nous devons convertir 
un bit (pseudo aléatoire) dans le flag CF en une valeur 0x5C ou 0x2F. 


^8http://trixter.oldskool.org/2012/12/17/maze- generation-in-thirteen-bytes/ 
49http://pferrie.host22.com/misc/10print.htm 
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Ceci est fait facilement: en AND-ant tous les bits de AL (oü tous les 8 bits sont mis ou 
effacés) nous obtenons 0 ou 0x2D. 


En ajoutant 0x2F à cette valeur, nous obtenons 0x5C ou 0x2F. 


Puis il suffit de l'afficher sur l'écran. 


Conclusion 


Il vaut la peine de mentionner que le résultat peut étre différent dans DOSBox, Win- 
dows NT et méme MS-DOS, 


à cause de conditions différentes: le chip timer peut étre émulé différemment et le 
contenu initial du registre peut étre différent aussi. 


0 -4 OY UBAUNRA 
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8.15.2 Ensemble de Mandelbrot 


Voici une démo”? écrite par «Sir Lagsalot» en 2009, qui dessine l'ensemble de Man- 
delbrot, qui est juste un programme x86, dont l'exécutable a une taille de seulement 
64 octets. Il y a seulement 30 instructions x86 16-bit. 


Voici ce qu'elle génére: 


DOSBox 0.74, Cpu speed: max 100% cycles, Frameskip 0, Program: MICROB~2 


Essayons de comprendre comment ca fonctionne. 


La démo, bien que minuscule (seulement 64 octets ou 30 instructions), implémente 
l'algorithme standard décrit ici, mais utilise des astuces de programmation. 


Le code source est facile à télé-charger, donc le voici, mais j'ai ajouté des commen- 
taires: 


Listing 8.25 : Code source commenté 


; X est une colonne de l'écran 
; Y est une ligne de l'écran 


; X=0, Y=0 X=319, Y=0 


50Téléchargeable ici, 
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| 

| 

| 

| 
PM 

X=0, Y=199 X=319, Y-199 


; mettre le mode graphique VGA 320*200*256 

mov al,13h 

int 10h 

; initialiser BX à O 

; initialiser DI à OxFFFE 

; DS:BX (ou DS:0) pointe à ce moment sur le Program Segment Prefix 
so... dont les 4 premiers octets sont CD 20 FF 9F 

les ax,[bx] 

; ES:AX=9FFF:20CD 


FillLoop: 

; mettre DX à 0. CWD fonctionne comme: DX:AX = sign extend(AX). 

; AX ici contient 0x20CD (au début) ou moins que 320 (lorsque l'on revient 
lors de la boucle), 

; donc DX contiendra toujours 0. 


cwd 

mov ax,di 

; AX est le pointeur courant dnas le buffer VGA 

; divise le pointeur courant par 320 

mov cx,320 

div cx 

; DX (start X) - reste (colonne: 0..319); AX - résultat (ligne: 0..199) 
sub ax,100 

; AX-AX-100, donc AX (start Y) est maintenant dans l'intervalle -100..99 
; DX est dans l'intervalle 0..319 ou 0x0000..0x013F 

dec dh 

; DX est maintenant dans l'intervalle OxFF00..0x003F (-256..63) 


xor bx,bx 
xor si,si 
; BX (temp X)=0; SI (temp Y)-0 


; prendre le nombre maximal d'itérations 
; CX contient toujours 320 ici, donc ceci est aussi le nombre maximal 


d'itérations 
MandelLoop: 
mov bp,si ; BP = temp_Y 
imul si,bx ; SI = temp X*temp Y 
add si,si ; SI = SI*2 = (temp X*temp Y)*2 
imul bx,bx ; BX = BX^2 = temp X^2 
jo MandelBreak ; overflow? 
imul bp,bp ; BP = BP^2 = temp Y^2 
jo MandelBreak ; overflow? 
add bx,bp ; BX = BX+BP = temp X^2 + temp Y^2 


jo MandelBreak ; overflow? 
sub bx,bp ; BX = BX-BP = temp X^2 + temp Y^2 - temp Y^2 = temp X^2 
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sub bx,bp ; BX = BX-BP = temp X^2 - temp Y^2 

; corrige l'échelle: 

sar bx,6 ; BX=BX/64 

add bx,dx ; BX=BX+start X 

; maintenant temp X = temp X^2 - temp Y^2 + start X 
sar si,6 ; SI-SI/64 

add si,ax ; SI=SI+start Y 


; maintenant temp Y = (temp X*temp Y)*2 + start Y 
loop MandelLoop 


MandelBreak: 

; CX=itérations 

xchg ax,cx 

; AX=itérations. stocke AL dans le buffer VGA en ES: [DI] 

stosb 

; stosb incrémente aussi DI, donc DI pointe maintenant sur le point suivant 


dans le buffer VGA MEN 
; saute toujours, donc c'est une boucle infinie ici 


jmp FillLoop 


Algorithme: 


e Change le mode vidéo à VGA 320*200 VGA, 256 couleurs. 320 x 200 = 64000 
(OxFAOO). 


Chaque pixel est encodé par un octet, donc la taille du buffer est de OxFAOO0 
octets. Il est accédé en utilisant la paire de registres ES:DI. 


ES doit être 0xAO000 ici, car c'est l'adresse du segment du buffer vidéo VGA, 
mais mettre 0xAOO00 dans ES nécessite au moins 4 octets (PUSH 0A000h / POP 
ES). Plus d'information sur le modéle de mémoire 16-bit de MS-DOS ici: 11.7 on 
page 1297. 


En supposant que BX vaut zéro ici, et que le Program Segment Prefix est à 
l'adresse zéro, l'instruction en 2 octets LES AX, [BX] stocke Ox20CD dans AX 
et Ox9FFF dans ES. 


Donc le programme commence à écrire 16 pixels (ou octets) avant le buffer 
vidéo. Mais c'est MS-DOS, 


Il n'y a pas de protection de la mémoire, donc l'écriture se produit tout à la fin 
de la mémoire conventionnelle, et en général, il n'y a rien d'important. C'est 
pourquoi vous voyez une bande rouge de 16 pixels de large sur le cóté droit. 
L'image compléte est décalée à gauche de 16 pixels. C'est le prix pour écono- 
miser 2 octets. 


Une boucle infinie traite chaque pixel. 


La facon la plus courante de parcourir tous les pixels de l'écran est d'utiliser 
deux boucles: une pour la coordonnée X, une autre pour la coordonnée Y. Mais 
vous devrez multiplier une coordonnée pour accéder à un octet dans le buffer 
vidéo VGA. 
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L'auteur de cette démo a décidé de faire autrement: énumérer tous les octets 
dans le buffer vidéo en utilisant une seule boucle au lieu de deux, et obtenir 
les coordonnées du point courant en utilisant une division Les coordonnées 
résultantes sont: X dans l'intervalle -256..63 et Y dans l'intervalle —100..99. Vous 
pouvez voir sur la copie d'écran que l'image est quelque peu décalée sur la 
droite de l'écran. 


C'est parce que la surface en forme de coeur apparait en général aux coor- 
données 0,0 et elles sont décalées vers la droite. Est-ce que l'auteur aurait pu 
soustraire 160 de la valeur pour avoir X dans l'intervalle -160..159? Oui, mais 
l'instruction SUB DX, 160 nécessite 4 octets, tandis que DEC DH—2 octets (ce 
qui soustrait 0x100 (256) de DX). Donc l'ensemble de l'image est décalée pour 
économiser 2 octets de code. 


- Vérifier si le point courant est dans l'ensemble de Mandelbrot. L'algorithme 
est celui qui a été décrit ici. 

- La boucle est organisée en utilisant l'instruction LOOP, qui utilise le registre 
CX comme compteur. 


L'auteur pourrait mettre le nombre d'itérations à une valeur spécifique, 
mais il ne l'a pas fait: 320 est déjà présent dans CX (il a été chargé à la 
ligne 35), et de toutes facons une bonne valeur d'itération maximale. Nous 
économisons encore un peu d'espace ici en ne rechargeant pas le registre 
CX avec une autre valeur. 


- IMUL est utilisé ici au lieu de MUL, car nous travaillons avec des valeurs 
signées: gardez à l'esprit que les coordonnées 0,0 doivent étre proches du 
centre de l'écran. 


C'est la méme chose avec SAR (décalage arithmétique pour des valeurs 
signées) : c'est utilisé au lieu de SHR. 


- Une autre idée est de simplifier le test des limites. Nous devons tester une 
paire de coordonnées, i.e., deux variables. Ce que je fais est de vérifier trois 
fois le débordement: deux opérations de mise au carré et une addition. 


En effet, nous utilisons des registres 16-bit, qui peuvent contenir des va- 
leurs signées dans l'intervalle -32768..32767, donc si l'une des coordon- 
nées est plus grande que 32767 lors de la multiplication signée, ce point 
est définitivement hors limites: nous sautons au label MandelBreak. 


- Il y a aussi une division par 64 (instruction SAR). 64 met à l'échelle. 


Il est possible d'augmenter la valeur pour regarder de plus prés, ou de la 
diminuer pour voir de plus loin. 


* Nous sommes au label MandelBreak, il y a deux façons d'arriver ici: la boucle 
s'est terminée avec CX=0 (le point est à l'intérieur de l'ensemble de Mandel- 
brot); ou parce qu'un débordement s'est produit (CX contient toujours une va- 
leur non zéro.) Nous écrivons la partie 8-bit basse de CX (CL) dans le buffer 
vidéo. 

La palette par défaut est grossiére, néanmoins, 0 est noir: ainsi nous voyons du 
noir aux endroits oü les points sont dans l'ensemble de Mandelbrot. La palette 
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peut étre initialisée au début du programme, mais gardez à l'esprit que ceci est 


un programme de seulement 64 octets! 


* le programme tourne en boucle infinie, car un test supplémentaire, ou une in- 
terface utilisateur quelconque nécessiterait des instructions supplémentaires. 


D'autres astuces d'optimisation: 


* L'instruction en 1-octet CWD est utilisée ici pour effacer DX au lieu de celle en 


2-octets XOR DX, DX ou méme celle en 3-octets MOV DX, 0. 


MOV AX,CX. La valeur courante de AX n'est plus nécessaire ici. 


début °1. 


L'instruction en 1-octet XCHG AX, CX est utilisée ici au lieu de celle en 2-octets 


DI (position dans le buffer vidéo) n'est pas initialisée, et contient OxFFFE au 


C'est OK, car le programme travaille pour tout DI dans l'intervalle 0..0xFFFF 
éternellement, et l'utilisateur ne peut pas remarquer qu'il a commencé en de- 
hors de l'écran (le dernier pixel d'un buffer vidéo de 320*200 est à l'adresse 
OxF9FF). Donc du travail est en fait effectué en dehors des limites de l'écran. 


Autrement, il faudrait une instruction supplémentaire pour mettre DI à O et 


tester la fin du buffer vidéo. 


Ma version «corrigée » 


Listing 8.26 : Ma version «corrigée » 


org 100h 

mov al,13h 
int 10h 

; définir la palette 
mov dx, 3c8h 
mov al, 0 
out dx, al 
mov cx, 100h 
inc dx 

100: 

mov al, cl 
shl ax, 2 


out dx, al ; rouge 
out dx, al ; vert 
out dx, al ; bleu 
loop 100 


push 0a000h 
pop es 


xor di, di 


FillLoop: 


51Plus d'information sur la valeur initiale des registres: https: //code.google.com/p/corkami/wiki/ 


InitialValues#D0S 
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cwd 

mov ax,di 
mov cx,320 
div cx 

sub ax,100 
sub dx,160 


xor bx,bx 
xor si,si 


MandelLoop: 
mov bp,si 

imul si,bx 

add si,si 

imul bx,bx 

jo MandelBreak 
imul bp,bp 

jo MandelBreak 
add bx,bp 

jo MandelBreak 
sub bx,bp 

sub bx,bp 


sar bx,6 
add bx,dx 
sar si,6 
add si,ax 


loop MandelLoop 


MandelBreak: 
xchg ax, cx 
stosb 

cmp di, OFAO00h 
jb FillLoop 


; attendre qu'une touche soit pressée 
xor ax,ax 

int 16h 

; mettre le mode vidéo texte 

mov ax, 3 

int 10h 

; Sortir 

int 20h 


J'ai essayé de corriger toutes ces bizarreries: maintenant la palette est un dégradé 
de gris, le buffer vidéo est à la bonne place (lignes 19..20), l'image est dessinée au 
centre de l'écran (ligne 30), le programme se termine et attend qu'une touche soit 
pressée (lignes 58..68). 


Mais maintenant c'est bien plus gros: 105 octets (ou 54 instructions) >. 


52Vous pouvez tester par vous-méme: prenez DosBox et NASM et compilez-le avec: nasm file.asm 
-fbin -o file.com 
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DOSBox 0.74, Cpu speed: 3000 cycles, Frameskip 0, Program: MY — 


Fig. 8.18: Ma version «corrigée » 


Voir aussi: petit programme C qui affiche l'ensemble de Mandelbrot en ASCII: https: 
//people.sc.fsu.edu/-jburkardt/c src/mandelbrot ascii/mandelbrot ascii. 
html 

https://miyuki.github.io/2017/10/04/gcc-archaeology-1.html. 


8.16 Un méchant bogue dans MSVCRT.DLL 


Ceci est un bogue qui m'a coúté plusieurs heures de débogage. 


En 2013, j'utilisais MinGW, mon projet C semblait tres instable et je voyais le mes- 
sage d'erreur “Invalid parameter passed to C runtime function.” dans le débogueur. 


Le message d'erreur était aussi visible en utilisant DebugView de Sysinternals. Et 
mon projet n'avait pas un tel message d'erreur, ni de chaíne. Donc, j'ai commencé 
à chercher dans l'ensemble de Windows et l'ai trouvé dans le fichier MSVCRT.DLL 
(inutile de dire que j'utilisais Windows 7). 


Donc le voici, le message d'erreur dans le fichier MSVCRT.DLL fourni avec Windows 
7: 


.text:6FFB69DO OutputString db ‘Invalid parameter passed to C runtime 7 
& function.',0Ah,0 
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| «text: 6FFB69D0 
sub 6FFB6930+83 


; DATA XREF: 


Oü est-il référencé? 


.text:6FFB6930 sub 6FFB6930 


CODE XREF: 


.text: 
.text: 
.text: 
.text: 
.text: 
: 6FFB6930 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
:6FFB6957 


.text 


.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
.text: 
: 6FFB69AA 


.text 


6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 


6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6930 
6FFB6932 
6FFB6933 
6FFB6935 
6FFB693B 
6FFB6940 
6FFB6942 
6FFB6945 
6FFB694B 
6FFB6951 


6FFB695D 
6FFB6963 
6FFB6969 
6FFB696F 
6FFB6975 
6FFB697B 
6FFB6981 
6FFB6987 
6FFB698D 
6FFB698E 
6FFB6994 
6FFB6997 
6FFB699D 
6FFB69A0 


proc near ; 
wfindfirst64+203FC 
; sub_6FF62563+319AD 

var_2D0 = dword ptr -2D6h 

var_244 = word ptr -244h 

var_240 = word ptr -240h 

var 23C = word ptr -23Ch 

var 238 = word ptr -238h 

var 234 - dword ptr -234h 

var 230 - dword ptr -230h 

var 22C - dword ptr -22Ch 

var 228 - dword ptr -228h 

var 224 - dword ptr -224h 

var 220 - dword ptr -220h 

var 21C - dword ptr -21Ch 

var 218 - dword ptr -218h 

var 214 - word ptr -214h 

var 210 - dword ptr -210h 

var 20C = dword ptr -20Ch 

var 208 = word ptr -208h 

var 4 - dword ptr -4 
mov edi, edi 
push ebp 
mov ebp, esp 
sub esp, 2D0h 
mov eax, | security cookie 
xor eax, ebp 
mov [ebp+var 4], eax 
mov [ebp+var 220], eax 
mov [ebp+var 224], ecx 
mov [ebp+var 228], edx 
mov [ebp+var_22C], ebx 
mov [ebp+var 230], esi 
mov [ebp+var 234], edi 
mov [ebp+var 208], ss 
mov [ebp+var 214], cs 
mov [ebp+var 238], ds 
mov [ebp+var 23C], es 
mov [ebp+var 240], fs 
mov [ebp+var 244], gs 
pushf 
pop [ebp+var 210] 
mov eax, [ebp+4] 
mov [ebp+var 218], eax 
lea eax, [ebp+4] 
mov [ebp+var_2D0], 10001h 
mov [ebp+var_20C], eax 


1192 


. text: 6FFB69B0 mov eax, [eax-4] 

. text: 6FFB69B3 push offset OutputString ; "Invalid 
parameter passed to C runtime f"... 

. text: 6FFB69B8 mov [ebp+var_21C], eax 

. text: 6FFB69BE call ds :OutputDebugStringA 

. text: 6FFB69C4 mov ecx, [ebp+var_4] 

. text: 6FFB69C7 xor ecx, ebp 

. text: 6FFB69C9 call @ security check cookies ; 

security check cookie(x) 
.text:6FFB69CE leave 
. text: 6FFB69CF retn 


. text: 6FFB69CF sub 6FFB6930 endp 


La chaine est affichée dans le débogueur ou l'utilitaire DebugView en utilisant la 
fonction standard 

OutputDebugStringA(). Comment la fonction sub 6FFB6930 peut-elle étre appe- 
lée? IDA montre au moins 290 références. En utilisant mon tracer, j'ai mis un point 
d'arrêt en sub 6FFB6930 pour voir quand elle est appelée dans mon cas. 


tracer.exe -l:1.exe bpf=msvcrt.dll!0x6FFB6930 -s 


PID=3560|New process 1.exe 

(0) msvcrt.d11!0x6ffb6930() (called from msvcrt.dll! ftol2 sse excpt+0v 
S X1b467 (0x759ed222)) 

Call stack: 

return address-0x401010 (1.exe!.text+0x10), arguments in stack: 0x12ff14, 07 
y x401010, 0x403010("asd"), 0x0, Ox12ff88, 0x4010f8 

return address=0x4010f8 (1.exe!0EP+0xe3), arguments in stack: 0x12ff88, Ov 
V x4010f8, 0x1, 0x2e0ea8, 0x2e1640, 0x403000 

return address=0x75b6ef3c (KERNEL32.dll!BaseThreadInitThunk40x12), 7 
y arguments in stack: 0x12ff94, Ox75b6ef3c, Ox7ffdf000, Ox12ffd4, Ov 
Y X77523688, Ox7ffdf000 

return address=0x77523688 (ntd11.d11!RtlInitializeExceptionChain+0xef), 2 
& arguments in stack: 0x12ffd4, 0x77523688, Ox7ffdf000, 0x74117ec7, 0x07 
V , 0x0 

return address=0x7752365b (ntd11.d11!RtlInitializeExceptionChain+0xc2), 2 
V arguments in stack: 0x12ffec, 0x7752365b, 0x401015, Ox7ffdf000, 0x0, 2 
y 0x0 

(0) msvcrt.dll!Ox6ffb6930() -> Ox12f94c 

PID=3560|Process 1.exe exited. ExitCode=2147483647 (Ox7fffffff) 


J'ai trouvé que mon code appelait la fonction stricmp() avec un argument à NULL. En 
fait, j'ai créé cet exemple en écrivant ceci: 


#include <stdio.h> 
#include <string.h> 


int main() 


{ 
}; 


stricmp ("asd", NULL); 
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Si ce morceau de code est compilé en utilisant un vieux MinGW ou un vieux MSVC 
6.0, il est lié avec le fichier MSVCRT.DLL. Qui, à partir de Windows 7, envoie silen- 
cieusement le message d'erreur “Invalid parameter passed to C runtime function.” 
au débogueur et puis ne fait rien! 


Voyons comment stricmp() est implémentée dans MSVCRT.DLL: 


.text:6FF5DB38 ; Exported entry 855. strcmpi 
.text:6FF5DB38 ; Exported entry 863. stricmp 
.text:6FF5DB38 

.text:6FF5DB38 ; =============== SUBROUTINE 


. text: 6FF5DB38 

.text:6FF5DB38 ; Attributes: bp-based frame 

. text: 6FF5DB38 

. text: 6FF5DB38 ; int cdecl strcmpi(const char *, const char *) 


. text: 6FF5DB38 public strcmpi 

.text:6FF5DB38 strcmpi proc near ; CODE XREF: 
LocaleEnumP roc -2B 

. text: 6FF5DB38 ; LocaleEnumProc+5E 


.text:6FF5DB38 
.text:6FF5DB38 arg 0 
.text:6FF5DB38 arg 4 
.text:6FF5DB38 
.text:6FF5DB38 ; FUNCTION CHUNK AT .text:6FF68CFD SIZE 00000012 BYTES 
.text:6FF5DB38 ; FUNCTION CHUNK AT .text:6FF9D20D SIZE 00000022 BYTES 
.text:6FF5DB38 


dword ptr 8 
dword ptr OCh 


. text: 6FF5DB38 mov edi, edi ; Strcmpi 

. text: 6FF5DB3A push ebp 

. text: 6FF5DB3B mov ebp, esp 

. text: 6FF5DB3D push esi 

. text: 6FF5DB3E xor esi, esi 

. text: 6FF5DB40 cmp dword 6FFF0000, esi 

.text:6FF5DB46 jnz loc 6FF68CFD 

.text:6FF5DBAC cmp [ebp+arg 0], esi ; is arg 0--NULL? 
.text:6FF5DB4F jz loc_6FF9D20D 

. text: 6FF5DB55 cmp [ebp+arg 4], esi ; is arg 0--NULL? 
.text:6FF5DB58 jz loc_6FF9D20D 

. text: 6FF5DB5E pop esi 

. text: 6FF5DB5F pop ebp 

.text:6FF5DB5F strcmpi endp ; sp-analysis failed 


La comparaison effective des chaines est ici: 


.text:6FF5DB60 sub 6FF5DB60 proc near ; CODE XREF: 
stricmp_1+16C7F 
. text: 6FF5DB60 ; Sub 6FFD19CD+229 


. text: 6FF5DB60 
.text:6FF5DB60 arg 0 
.text:6FF5DB60 arg 4 
.text:6FF5DB60 


dword ptr 8 
dword ptr Ch 


. text: 6FF5DB60 push ebp 
. text: 6FF5DB61 mov ebp, esp 
. text: 6FF5DB63 push edi 


. text: 6FF5DB64 push esi 
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text: 
.text: 
.text: 
.text: 
.text: 


6FF5DB65 
6FF5DB66 
6FF5DB69 
6FF5DB6C 
6FF5DB6E 
. text: 6FF5DB70 
.text:6FF5DB70 loc 6FF5DB70: 
sub 6FF5DB60+20 
.text:6FF5DB70 
.text:6FF5DB70 
.text:6FF5DB72 
.text:6FF5DB74 
.text:6FF5DB76 
.text:6FF5DB79 
.text:6FF5DB7B 
.text:6FF5DB7E 
. text: 6FF5DB80 
. text: 6FF5DB82 
.text:6FF5DB84 
.text:6FF5DB86 
. text: 6FF5DB88 
. text: 6FF5DB8B 
. text: 6FF5DB8D 
. text: 6FF5DB8F 
. text: 6FF5DB91 
. text: 6FF5DB93 
. text: 6FF5DB95 
. text: 6FF5DB97 
. text: 6FF5DB9A 
. text: 6FF5DB9C 
. text: 6FF5DB9E 
. text: 6FF5DBA0 
. text: 6FF5DBA2 
. text: 6FF5DBA4 
. text: 6FF5DBA6 
.text:6FF5DBA6 loc 6FF5DBA6: 
sub 6FF5DB60+12 
. text: 6FF5DBA6 
. text: 6FF5DBA9 
. text: 6FF5DBAA 
. text: 6FF5DBAB 
. text: 6FF5DBAC 
. text: 6FF5DBAD 
.text:6FF5DBAD sub 6FF5DB60 


.text:6FF68D0C loc 6FF68D60C: 
strcmpi-3F6F2 

.text:6FF68D0C 

.text:6FF68D0D 

. text: 6FF68D0E 


.text:6FF9D20D loc 6FF9D20D: 
strcmpi+17 
.text:6FF9D20D 


push 
mov 
mov 
mov 
mov 


or 
jz 
mov 
add 
mov 
add 
cmp 
jz 
sub 
cmp 
sbb 
and 
add 
add 
xchg 
sub 
cmp 
sbb 
and 
add 
add 
cmp 
jz 
sbb 
sbb 


movsx 
pop 
pop 
pop 
leave 
retn 
endp 


pop 
pop 
retn 


ebx 

esi, [ebptarg 4] 
edi, [ebptarg 0] 
al, OFFh 

edi, edi 


; CODE XREF: 


; sub 6FF5DB60+40 
al, al 
short loc_6FF5DBA6 
al, [esi] 
esi, 1 
ah, [edi] 
edi, 1 
ah, al 
short loc_6FF5DB70 
al, 41h 
al, 
cl, cl 
cl, 
al, cl 
al, 
ah, al 


al, ah 

short loc 6FF5DB70 
al, al 

al, OFFh 


; CODE XREF: 


eax, al 
ebx 
esi 
edi 


; CODE XREF: 
esi 
ebp 

; CODE XREF: 


; strcmpi+20 
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.text:6FF9D20D call near ptr _errno 
.text:6FF9D212 push esi 

. text: 6FF9D213 push esi 

. text: 6FF9D214 push esi 

. text: 6FF9D215 push esi 

. text: 6FF9D216 push esi 

. text: 6FF9D217 mov dword ptr [eax], 16h 
. text: 6FF9D21D call invalid parameter 
.text:6FF9D222 add esp, 14h 
.text:6FF9D225 mov eax, 7FFFFFFFh 
.text:6FF9D22A jmp loc 6FF68DO0C 


Maintenant la fonction invalid parameter() : 


.text:6FFB6A06 public invalid parameter 
.text:6FFB6A06 invalid parameter proc near ; CODE XREF: 
sub 6FF5B494:loc 6FF5B618 
.text:6FFB6A06 
sub 6FF5CCFD:loc 6FF5C8A2 


. text: 6FFB6A06 mov edi, edi 

. text: 6FFB6A08 push ebp 

. text: 6FFB6A09 mov ebp, esp 

. text: 6FFB6A0B pop ebp 

. text: 6FFB6A0C jmp sub_6FFB6930 


.text:6FFB6A0C invalid parameter endp 


La fonction invalid parameter() appelle finalement la fonction avec OutputDebugStringA(): 
8.16 on page 1191. 


Voyez-vous, le code de stricmp() est comme: 


int stricmp(const char *s1, const char *s2, size t len) 
| if (sl==NULL || s2==NULL) 
: // print error message AND exit: 
return Ox7FFFFFFFh; 
: ij do comparison 


Comment se fait-il que cette erreur soit rare? Car les nouvelles versions de MSVC 
lient avec le fichier MSVCR120.DLL, etc. (où 120 est le numéro de version). 


Jetons un coup d'oeil à l'intérieur du nouveau MSVCR120.DLL de Windows 7: 


. text: 1002A0D4 public stricmp l 

.text:1002A0D4 stricmp 1l proc near ; CODE XREF: 
stricmp+18 

.text:1002A0D4 ; mbsicmp 1+47 

.text:1002A0D4 ; DATA XREF: 


. text: 1002A0D4 
.text:1002A0D4 var 10 
.text:1002A0D4 var 8 


dword ptr -10h 
dword ptr -8 
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.text:1002A0D4 var 4 
.text:1002A0D4 arg 0 
.text:1002A0D4 arg 4 
.text:1002A0D4 arg 8 
.text:1002A0D4 


byte ptr -4 
dword ptr 8 
dword ptr OCh 
dword ptr 10h 


.text:1002A0D4 ; FUNCTION CHUNK AT .text:1005AA7B SIZE 0000002A BYTES 


.text:1002A0D4 


. text: 1002A0D4 push ebp 

. text: 1002A0D5 mov ebp, esp 

. text: 1002A0D7 sub esp, 10h 

. text: 1002A0DA lea ecx, [ebp+var 10] 

.text:1002A0DD push ebx 

.text:1002A0DE push esi 

.text:1002A0DF push edi 

. text: 1002A0E0 push [ebp+arg_ 8] 

. text: 1002A0E3 call sub_1000F764 

. text: 1002A0E8 mov edi, [ebp+arg 0] ; arg==NULL? 

.text:1002A0EB test edi, edi 

.text:1002A0ED jz loc 1005AA7B 

.text:1002A0F3 mov ebx, [ebp+arg 4] ; arg==NULL? 

.text:1002A0F6 test ebx, ebx 

.text:1002A0F8 jz loc 1005AA7B 

.text:1002A0FE mov eax, [ebp+var_10] 

.text:1002A101 cmp dword ptr [eax+0A8h], 0 

.text:1002A108 jz loc 1005AA95 

.text:1002A10E sub edi, ebx 

.text:1005AA7B loc 1005AA7B: ; CODE XREF: 
stricmp 1+19 — 

.text:1005AA7B ; Stricmp 1+24 

.text:1005AA7B call _errno 

. text: 1005AA80 mov dword ptr [eax], 16h 

. text: 1005AA86 call _invalid_parameter_noinfo 

. text: 1005AA8B mov esi, 7FFFFFFFh 

.text:1005AA90 jmp loc 1002A13B 

.text:100A4670 invalid parameter noinfo proc near ; CODE XREF: 
sub 10013BEC-10F 

.text:100A4670 ; sub 10016COF-10F 

.text:100A4670 xor eax, eax 

.text:100A4672 push eax 

.text:100A4673 push eax 

.text:100A4674 push eax 

.text:100A4675 push eax 

.text:100A4676 push eax 

.text:100A4677 call invalid parameter 

.text:100A467C add esp, 14h 

.text:100A467F retn 


.text:100A467F invalid parameter noinfo endp 
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.text:100A4645 invalid parameter proc near ; CODE XREF: 
invalid parameter(ushort const *,ushort const *,ushort const 


* uint,uint) 
.text:100A4645 


invalid parameter noinfo+7 


.text:100A4645 
.text:100A4645 arg 0 
.text:100A4645 arg 4 
.text:100A4645 arg 8 
.text:100A4645 arg C 
.text:100A4645 arg 10 
.text:100A4645 
.text:100A4645 
.text:100A4646 
.text:100A4648 
.text:100A464E 
.text:100A4654 
.text:100A4656 
.text:100A4658 
.text:100A4659 
.text:100A465B ; 


.text:100A465B 
.text:100A465B loc 100A465B: 
invalid parameter+11 
.text:100A465B 
.text:100A465E 
.text:100A4661 
.text:100A4664 
.text:100A4667 
.text:100A466A 
.text:100A466F 


.text:100A466F invalid parameter endp 


.text:100A469B invoke watson 


sub 1002CDB0+27068 
.text:100A469B 
.text:100A469B 
.text:100A469D 
. text: 100A46A2 
. text: 100A46A4 
. text: 100A46A6 
. text: 100A46A8 
. text: 100A46A9 
RtlFailFast(ecx) 
. text: 100A46AB ; 
. text: 100A46AB 
.text:100A46AB loc 100A46AB: 
invoke watson+9 
.text:100A46AB 
.text:100A46AC 
.text:100A46AE 


, 


- dword ptr 8 
= dword ptr OCh 
- dword ptr 10h 
= dword ptr 14h 
= dword ptr 18h 
push ebp 
mov ebp, esp 
push dword_100E0ED8 ; Ptr 
call ds:DecodePointer 
test eax, eax 
jz short loc 100A465B 
pop ebp 
jmp eax 
; CODE XREF: 
push [ebp+arg_10] 
push [ebp+arg_C] 
push [ebp+arg_8] 
push [ebp+arg_4] 
push [ebp+arg_0] 
call _invoke watson 
int 3 ; Trap to Debugger 
proc near ; CODE XREF: 
; sub 10029704+2A792 
push 17h ; ProcessorFeature 
call IsProcessorFeaturePresent 
test eax, eax 
jz short loc 100A46AB 
push 5 
pop ecx 
int 29h ; Win8: 
; CODE XREF: 
push esi 
push 1 
mov esi, 0C0000417h 
push esi 


. text: 100A46B3 
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. text: 100A46B4 push 2 

. text: 100A46B6 call sub_100A4519 

. text: 100A46BB push esi ; uExitCode 
. text: 100A46BC call _ crtTerminateProcess 
.text:100A46C1 add esp, 10h 

. text: 100A46C4 pop esi 

. text: 100A46C5 retn 


.text:100A46C5 invoke watson endp 


Maintenant la fonction invalid parameter() est récrite dans les nouvelles versions 
de MSVCR*.DLL, elle montre la boite de dialogue, proposant de tuer le processus ou 
d'appeler le débogueur. Bien súr, c'est beaucoup mieux que de retourner silencieu- 
sement. Peut-étre que Microsoft a oublié de fixer MSVCRT.DLL depuis lors. 


Mais comment est-ce que ca fonctionnait du temps de Windows XP? Ca ne fonction- 
nait pas: MSVCRT.DLL de Windows XP ne vérifiait pas si les arguments étaient NULL. 
Donc, sous Windows XP mon code stricmp ("asd", NULL) plantera, et c’est bien. 


Mon hypothése: Microsoft a mis a jour les fichiers MSVCR*.DLL (MSVCRT.DLL inclus) 
pour Windows 7 en ajoutant des tests de vérification partout. Toutefois, puisque 
MSVCRT.DLL n'était plus beaucoup utilisé depuis MSVS .NET (année 2002), il n'a pas 
été testé proprement et le bogue est resté. Mais des compilateurs comme MinGW 
peuvent toujours utiliser cette DLL. 


Qu'aurais-je fait sans mes compétences en rétro-ingénierie? 
Le fichier MSVCRT.DLL de Windows 8.1 a le méme bogue. 


8.17 Autres exemples 


Un exemple à propos de Z3 et de la décompilation manuelle se trouvait ici. Il est 
(temporairement) déplacé là: https://sat-smt.codes. 


Chapitre 9 


Exemples de Reverse 
Engineering de format de 
fichier propriétaire 


9.1 Chiffrement primitif avec XOR 


9.1.1 Chiffrement XOR le plus simple 


J'ai vu une fois un logiciel oü tous les messages de débogage étaient chiffrés en 
utilisant XOR avec une valeur de 3. Autrement dit, les deux bits les plus bas de 
chaque caractères étaient inversés. 


“Hello, world” devenait “Kfool/#tlqog”: 
Listing 9.1 : Python 


#!/usr/bin/python 
msg="Hello, world!" 


print "",join(map(lambda x: chr(ord(x)^3), msg) ) 


Ceci est un chiffrement assez intéressant (ou plutót une obfuscation), car il posséde 
deux propriétés importantes: 1) fonction unique pour le chiffrement/déchiffrement, 
il suffit de l'appliquer à nouveau; 2) les caractéres résultants sont aussi imprimable, 
donc la chaine compléte peut étre utilisée dans du code source, sans caractéres 
d'échappement. 


La seconde propriété exploite le fait que tous les caractéres imprimables sont orga- 
nisés en lignes: 0x2x-0x7x, et lorsque vous inversez les deux bits de poids faible, le 
caractére est déplacé de 1 ou 3 caractéres à droite ou à gauche, mais n'est jamais 
déplacé sur une autre ligne (peut-étre non imprimable) : 


1199 


1200 


Fig. 9.1: Table ASCII 7-bit dans Emacs 


...avec la seule exception du caractére Ox7F. 


Par exemple, chiffrons les caractéres de l'intervalle A-Z: 


#!/usr/bin/python 
msg="@ABCDEFGHIJKLMNO" 


print "".join(map(lambda x: chr(ord(x)^3), msg) ) 


Résultat: CBA@GGFEDKJIHONML. 
C'est comme si les caractères “O” et "C" avaient été échangés, ainsi que "B" et “a”. 


Encore une fois, ceci est un exemple intéressant de l'exploitation des propriétés de 
XOR plutót qu'un chiffrement: le méme effet de préservation de l'imprimabilité peut 
étre obtenu en échangeant chacun des 4 bits de poids faible, avec n'importe quelle 
combinaison. 
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9.1.2 Norton Guide: chiffrement XOR a 1 octet le plus simple 
possible 


Norton Guide était trés populaire à l'époque de MS-DOS, c'était un programme ré- 
sident qui fonctionnait comme un manuel de référence hypertexte. 


Les bases de données de Norton Guide étaient des fichiers avec l'extension .ng, dont 
le contenu avait l'air chiffré: 


view X86.NG - Far 2.0.1807 x64 Administrator vj 


t> [>> 
(+ 3 ~ 3 3 2 
> t1 touet> 
iw4>4k4>Ub4>N>> 


>>>>YJ0>Stinhoyn 
sut:ion-Ho}sinoh 
i>Jhunoynsut6:jh 
s1svaja> byajnsu 
ti>[="hoiist):wu 
~Oi-Ujyu~oi-t-Q 
21251222 

>>>! pi lua>> 
——————— cp 
>>> JO5Stinh 
oynsut: ian-Ha}si 
nohi6:~{n{:ncjoi 


13-14 

p La 
D o 
WWB=Stinhoynsut: 
iôn----Jlollh-xxx 


IKO. Jb8>>My be> 

2cir:^[119»241^ 
3293167-^31g (^71 
EVideo B 


Fig. 9.2: Aspect trés typique 


Pourquoi pensons-nous qu'il est chiffré mais pas compressé? 


Nous voyons que l'octet Ox1A (ressemblant à «—») est trés fréquent, ça ne serait 
pas possible dans un fichier compressé. 


Nous voyons aussi de longues parties constituées seulement de lettres latines, et 
qui ressemble à des chaines de caractéres dans un langage inconnu. 
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Puisque l'octet Ox1A revient si souvent, nous pouvons essayer de décrypter le fichier, 
en supposant qu'il est chiffré avec le chiffrement XOR le plus simple. 


Si nous appliquons un XOR avec la constante Ox1A à chaque octet dans Hiew, nous 
voyons des chaínes de texte familiéres en anglais: 


X86.NG BFUO EDITMODE 0000032F 
00000170: 02 00-A9 00 BB 
00000180: ee 00-00 00 B 
00000190: 02 00-F3 E8 xB +n8 
000001A0: 03 00-54 00 sm rqBl OAR 
000001B0: 00 00-6E 00 d 
000001C0: eg 08-8F ee A 
000001D0: 00 00-A8 00 a M 
000001E0: 73 74-72 75 CPU Instruct 
000001F0: 67 69-73 74 ion set Register 
00000200: 6F 6E-2C 20 s Protection, pr 
00000210: 63 65-70 74 ivilege Exceptio 
00000220: 69 6E-67 20 ns Addressing mo 
00000230: 73 00-00 02 des Opcodes BK 
00000240: og 00-00 00 B B 
00000250: 00 83-B2 04 8 ria $ 
00000260: 00 00-00 00 4 J 
00000270: 00 49-6E 73 FPU Instr 
00000280: 00 52-65 67 uction set Regis 
00000290: 20 74-79 70 ters, data types 
000002A0: ee 00-00 00 a) AD 
00000280: 08 08-B6 DC 112 
000002C0: ee 00-00 00 B ( 
000002D0: 63 74-69 6F MMX Instruction 
000002E0: 08 00-00 FF set car 
000002F0: 00 00-00 00 Bl 
00000300: 57-03 BPA 48x8 aya 
00000310: 24 00-00 B3 yBh WES |B 
00000320: 03 7D-32 08 lge- -8)2 B 

o MM Er E E E g 1: 


Fig. 9.3: XOR dans Hiew avec Ox1A 


Le chiffrement XOR avec un seul octet constant est la méthode de chiffrement la 
plus simple, que l'on rencontre néanmoins parfois. 


Maintenant, nous comprenons pourquoi l'octet Ox1A revenait si souvent: parce qu'il 
y a beaucoup d'octets à zéro et qu'ils sont remplacés par Ox1A dans la forme chiffrée. 


Mais la constante pourrait étre différente. Dans ce cas, nous pourrions essayer chaque 
constante dans l'intervalle 0..255 et chercher quelque chose de familier dans le fi- 
chier déchiffré. 256 n'est pas si grand. 
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Plus d'informations sur le format de fichier de Norton Guide: http: //www.davep. 
org/norton-guides/file-format/. 


Entropie 


Une propriété trés importante de tels systémes de chiffrement est que l'entropie des 
blocs chiffrés/déchiffrés est la méme. 


Voici mon analyse faite dans Wolfram Mathematica 10. 


Listing 9.2 : Wolfram Mathematica 10 


In[1]:= input = BinaryReadList["X86.NG"]; 


In[2]:= Entropy[2, input] // N 
Out[2]2 5.62724 


In[3]:= decrypted = Map[BitXor[#, 16^^1A] €, input]; 


In[4]:= Export["X86 decrypted.NG", decrypted, "Binary"]; 


In[5]:= Entropy[2, decrypted] // N 

Out[5]= 5.62724 

In[6]:= Entropy[2, ExampleData[{"Text", "ShakespearesSonnets"}]] // N 
Out[6]= 4.42366 


Ici, nous chargeons le fichier, obtenons son entropie, le déchiffrons, le sauvons et 
obtenons a nouveau son entropie (la méme!). 


Mathematica fourni également quelques textes en langue anglaise bien connus pour 
analyse. 


Nous obtenons ainsi l'entropie de sonnets de Shakespeare, et elle est proche de 
l'entropie du fichier que nous venons d'analyser. 


Le fichier que nous avons analysé consiste en des phrases en langue anglaise, qui 
sont proches du langage de Shakespeare. 


Et le texte en langue anglaise XOR-é posséde la méme entropie. 


Toutefois, ceci n'est pas vrai lorsque le fichier est XOR-é avec un pattern de plus d'un 
octet. 


Le fichier qui vient d'étre analysé peut étre téléchargé ici: http://beginners.re/ 
examples/norton guide/X86.NG. 


Encore un mot sur la base de l'entropie 


Wolfram Mathematica calcule l'entropie avec une base e (base des logarithmes na- 
turels), et l'utilitaire UNIX ent utilise une base 2. 


Thttp://ww. fourmilab.ch/random/ 
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Donc, nous avons mis explicitement une base 2 dans la commande Entropy, donc 
Mathematica nous donne le méme résultat que l'utilitaire ent. 
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9.1.3 Chiffrement le plus simple possible avec un XOR de 4- 
octets 


Si un pattern plus long était utilisé, comme un pattern de 4 octets, ca serait facile a 
repérer. 


Par exemple, voici le début du fichier kernel32.dll (version 32-bit de Windows Server 
2008) : 


Hiew: kernel32.dll o 
p2\kerne132.d11 BFRO -------- __ PE .7DD60000|Hiew 8.02 (c)SEN - 


Fig. 9.4: Fichier original 


Ici, il est «chiffré » avec une clef de 4-octet: 


w: kernel32.dll.encrypted 


Fig. 9.5: Fichier «chiffré » 


Il est facile de repérer les 4 symboles récurrents. 


En effet, l'entéte d'un fichier PE comporte de longues zones de zéro, ce qui explique 
que la clef devient visible. 
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Voici le début d'un entéte PE au format hexadécimal: 


C:\tmp2\kerne132.d11 FRO -------- PE .7DD60290 
. 70D600E0: 
. 7DD600F0: EbĒS 
.70D60100: Bp 
. 7DD60110: 
. 7DD60120: 
.7DD60130: 
.7DD6014 : 
.7DD60150: 
.70D60160: 
.70D60170: 
.70D60180: 
. 70060190: 
.7DD601A0 : 
. 7DD601B0 : 
. 7DD691C0: 
.70D601D0: 
. 7DD601E0: 
. 7DD601F 0: 
.70D60200: 
.70D60210: 
.70D60220: 
.70D60230: 
.70D60240: 
.70D60250: 
.7DD60260 : 
.7DD60270 : 
.70D60280: 
.7DD60290: [E 


Ba 
o Es 


E 


Fig. 9.6: Entéte PE 
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Le voici «chiffré » : 


C:\tmp2\kernel32.dll.encrypted BFRO -------- 00000299 
000000E0: 8C 61 D2 63-8C 61 MarcMarcæ$rc ‘IE 
e000Q0FO: 09 FB C7 30-8C 61 Bv [MaycMaycla%B 
00000100: 87 60 DB 63-8C 61 3" icmallcMascMayc 
00000110: 1F 53 D3 63-8C 61 gs cMalictallc Mab 
00000120: 8C 61 D3 63-8C 61 MallcMallcKallckallc 
00000130: 8A 61 D3 63-8C 61 KallcMarcMa |-cMallc 
00000140: 22 64 C3 63-8F 61 "d fcnaTbMa pcMqyc 
00000150: 8C 61 C2 63-8C 71 MaycMqycMarcbarc 
00000160: FC 9E D9 63-3D C8 mol c- Ercut [oc ve 
00000170: 8C 61 DD 63-A4 64 Mal cadycMagcMagc 
00000180: 8C 61 D2 63-8C 61 MaycMaycMayc8lbye 
00000190: B8 66 DF 63-B4 61 le edema Lin 
00000140: 8C 61 D2 63-8C 61 MarcMarcMarcMarc 
00008188: 9C 54 DA 63-CC 61 bT charcercMarc 
000081C0: 8C 61 D3 63-7C 6C Mallc|1rcMarcMarc 
000001D0: 8C 61 D2 63-8C 61 MarcMarcMa bal la 
000001E0: A2 15 B7 1B-F8 61 gg had bei cMallc 
000001F0: 8C 61 DF 63-8C 61 MallcMa ma [morc 


00000200: 8C 61 D2 63-AC 61 Maycmay3e8 | Baagc 
00000210: 80 71 D2 63-8C 61 AqycMagcMa cMagc 
00000220: 8C 61 D2 63-8C 61 MagcMagcMagc agr 
00000230: A2 13 A1 11-EF 61 eB6Baa Bieb gi 
00000240: 8C 61 D3 63-8C 61 MalcMa] cMaycMayc 


00000250: 8C 61 D2 63-CC 61 Merc forie ac 


00000260: 10 CC D2 63-8C 61 AlbrcMaycMa cMarc 
00000270: 8C 61 D2 63-8C 61 MagycMagcMagc fay! 
00000280: 8C 61 D2 63-8C 61 MarcMarcMarcMac 
00000290: [f$ 61 D2 63-8C 61 GaycMaycMaycMayc 
1Globa1 2F1181k 3CryBIk LAN 5 EEstringDirect§&Table IE 10 leave 11 


Fig. 9.7: Entéte PE «chiffré » 


Il est facile de repérer que la clef est la séquence de 4 octets suivant: 8C 61 D2 63. 
Avec cette information, c'est facile de déchiffrer le fichier entier. 


Il est important de garder à l'esprit ces propriétés importantes des fichiers PE: 1) 
l'entéte PE comporte de nombreuses zones remplies de zéro; 2) toutes les sections 
PE sont complétées avec des zéros jusqu'à une limite de page (4096 octets), donc 
il y a d'habitude de longues zones à zéro aprés chaque section. 


Quelques autres formats de fichier contiennent de longues zones de zéro. 
C'est typique des fichiers utilisés par les scientifiques et les ingénieurs logiciels. 


Pour ceux qui veulent inspecter ces fichiers eux-méme, ils sont téléchargeables ici: 
http://beginners.re/examples/XOR 4byte/. 
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Exercice 


* http://challenges.re/50 


9.1.4 Chiffrement simple utilisant un masque XOR 


J'ai trouvé un vieux jeu de fiction interactif en plongeant profondément dans if- 
archive? : 


The New Castle v3.5 - Text/Adventure Game 

in the style of the original Infocom (tm) 

type games, Zork, Collosal Cave (Adventure), 

etc. Can you solve the mystery of the 

abandoned castle? 

Shareware from Software Customization. 

Software Customization [ASP] Version 3.5 Feb. 2000 


Il est téléchargeable ici. 


Il y a un fichier à l'intérieur (appelé castle.dbf) qui est visiblement chiffré, mais pas 
avec un vrai algorithme de crypto, qui n'est pas non plus compressé, il s'agit plutót 
de quelque chose de plus simple. Je ne vais méme pas mesurer le niveau d'entropie 
(9.2 on page 1225) du fichier, car je suis sür qu'il est bas. Voici à quoi il ressemble 
dans Midnight Commander: 


uqo 
UP, Jiq Qt : Q E j..hw.m.j a 
uPd. tq o cmrf. : j..hw.m.j a 
UP dg x m .uECTu 
uP, Jig G B : T «hum. j a 
.uPd. tq cmr f f ta E ore me Ji o8 
uP a 7 \A i e j. hum. j 
cum. m 


Fig. 9.8: Fichier chiffré dans Midnight Commander 


Le fichier chiffré peut étre téléchargé ici: . 


2http://ww.ifarchive.org/ 
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Sera-t-il possible de le décrypter sans accéder au programme, en utilisant juste ce 
fichier? 


Il y a clairement un pattern visible de chaines répétées. Si un simple chiffrement 
avec un masque XOR a été appliqué, une répétition de telles chaines en est une 
signature notable, car, il y avait probablement de longues suites (lacunes?) d'octets 
à zéro, qui, à tour de rôle, sont présentes dans de nombreux fichiers exécutables, 
tout comme dans des fichiers de données binaires. 


Ici, je vais afficher le début du fichier en utilisant l'utilitaire UNIX xxd : 


0000030: 09 61 Od 63 Of 77 14 69 75 62 67 76 01 7e 1d 61 .a.c.w.iubgv.-.a 
0000040: 7a 11 Of 72 6e 03 05 7d 7d 63 7e 77 66 le 7a 02 z..rn..}}c-wf.z. 
0000050: 75 50 02 4a 31 71 31 33 5c 27 08 5c 51 74 3e 39 uP.J1q13\'.\Qt>9 
0000060: 50 2e 28 72 24 4b 38 21 4c 09 37 38 3b 51 41 2d P.(r$K8!L.78;QA- 
0000070: 1c 3c 37 5d 27 5a 1c 7c 6a 10 14 68 77 08 6d la .«7]'Z.|j..hw.m. 


0000080: 6a 09 61 Od 63 Of 77 14 69 75 62 67 76 01 7e 1d j.a.c.w.iubgv.-. 
0000090: 61 7a 11 Of 72 6e 03 05 7d 7d 63 7e 77 66 le 7a az..rn..}}c-wf.z 
0000020: 02 75 50 64 02 74 71 66 76 19 63 08 13 17 74 7d .uPd.tqfv.c...t} 
00000b0: 6b 19 63 6d 72 66 0e 79 73 1f 09 75 71 6f 05 04 k.cmrf.ys..uqo.. 
00000c0: 7f 1c 7a 65 08 6e 0e 12 7c 6a 10 14 68 77 08 6d ..ze.n..|j..hw.m 


00000d0: la 6a 09 61 Od 63 Of 77 14 69 75 62 67 76 01 7e .j.a.c.w.iubgv.- 
00000e0: 1d 61 7a 11 Of 72 6e 03 05 7d 7d 63 7e 77 66 le .az..rn..}}c-wf. 
00000f0: 7a 02 75 50 01 4a 3b 71 2d 38 56 34 5b 13 40 3c z.uP.J;q-8V4[.@< 
0000100: 3c 3f 19 26 3b 3b 2a Oe 35 26 4d 42 26 71 26 4b <?.&;;*. 58MB&q&K 
0000110: 04 2b 54 3f 65 40 2b 4f 40 28 39 10 5b 2e 77 45 .+T?e@+0@(9.[.WwE 


0000120: 28 54 75 09 61 Od 63 Of 77 14 69 75 62 67 76 01 (Tu.a.c.w.iubgv. 
0000130: 7e 1d 61 7a 11 Of 72 6e 03 05 7d 7d 63 7e 77 66 -.az..rn..}}c-wf 
0000140: le 7a 02 75 50 02 4a 31 71 15 3e 58 27 47 44 17 .z.uP.J1q.»X'GD. 
0000150: 3f 33 24 4e 30 6c 72 66 0e 79 73 1f 09 75 71 6f ?3$NOlrf.ys..ugo 
0000160: 05 04 7f 1c 7a 65 08 6e 0e 12 7c 6a 10 14 68 77  ....ze.n..|j..hw 


Concentrons-nous sur la chaîne visible iubgv se répétant. En regardant ce dump, 
nous voyons clairement que la période de l'occurrence de la chaine est 0x51 ou 81. 
La taille du fichier est 1658961, et est divisible par 81 (et il y a donc 20481 blocs). 


Maintenant, je vais utiliser Mathematica pour l'analyse, y a-t-il des blocs de 81 oc- 
tets se répétant dans le fichier? Je vais séparer le fichier d'entrée en blocs de 81 
octets et ensuite utiliser la fonction Tally[]* qui compte simplement combien de fois 
un élément était présent dans la liste en entrée. La sortie de Tally n'est pas triée, 
donc je vais ajouter la fonction Sort[] pour trier le nombre d'occurrences par ordre 
décroissant. 


input = BinaryReadList["/home/dennis/.../castle.dbf"]; 


3Comme dans https://en.wikipedia.org/wiki/Lacuna (manuscripts) 
4https://reference.wolfram.com/language/ref/Tally. html 
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blocks = Partition[input, 81]; 


stat = Sort[Tally[blocks], #1[[2]] > #2[[2]] 81 


Et voici la sortie: 


(1180, 103, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, 125, 107, 
25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 111, 5, 4, 
127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 104, 119, 8, 
109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 
1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 
119, 102, 30, 122, 2, 117), 1739], 

(180, 100, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, 

125, 107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 
111, 5, 4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 
104, 119, 8, 109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 
98, 103, 118, 1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 
125, 99, 126, 119, 102, 30, 122, 2, 117], 1422], 

(180, 101, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, 

125, 107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 
111, 5, 4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 
104, 119, 8, 109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 
98, 103, 118, 1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 
125, 99, 126, 119, 102, 30, 122, 2, 117], 1012], 

(180, 120, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, 

125, 107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 
111, 5, 4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 
104, 119, 8, 109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 
98, 103, 118, 1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 
125, 99, 126, 119, 102, 30, 122, 2, 117], 377], 


(180, 2, 74, 49, 113, 21, 62, 88, 39, 71, 68, 23, 63, 51, 36, 78, 48, 
108, 114, 102, 14, 121, 115, 31, 9, 117, 113, 111, 5, 4, 127, 28, 
122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 104, 119, 8, 109, 26, 
106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 1, 126, 
29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 102, 
30, 122, 2, 117), 1], 

(180, 1, 74, 59, 113, 45, 56, 86, 52, 91, 19, 64, 60, 60, 63, 

25, 38, 59, 59, 42, 14, 53, 38, 77, 66, 38, 113, 38, 75, 4, 43, 84, 
63, 101, 64, 43, 79, 64, 40, 57, 16, 91, 46, 119, 69, 40, 84, 117, 
9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 1, 126, 29, 

97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 102, 30, 

122, 2, 117), 1], 

((80, 2, 74, 49, 113, 49, 51, 92, 39, 8, 92, 81, 116, 62, 57, 

80, 46, 40, 114, 36, 75, 56, 33, 76, 9, 55, 56, 59, 81, 65, 45, 28, 
60, 55, 93, 39, 90, 28, 124, 106, 16, 20, 104, 119, 8, 109, 26, 

106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 1, 126, 

29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 102, 

30, 122, 2, 117), 1}} 
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La sortie de Tally est une liste de paires, chaque paire a un bloc de 81 octets et le 
nombre de fois qu'il apparait dans le fichier. Nous voyons que le bloc le plus fréquent 
est le premier, il est apparu 1739 fois. Le second apparaît 1422 fois. Puis les autres: 
1012 fois, 377 fois, etc. Les blocs de 81 octets qui ne sont apparus qu'une fois sont 
à la fin de la sortie. 


Essayons de comparer ces blocs. Le premier et le second. Y a-t-il une fonction dans 
Mathematica qui compare les listes/tableaux? Certainement qu'il y en a une, mais 
dans un but didactique, je vais utiliser l'opération XOR pour la comparaison. En effet: 
si les octets dans deux tableaux d'entrée sont identiques, le résultat du XOR est O. 
Si ils sont différents, le résultat sera différent de zéro. 


Comparons le premier bloc (qui apparaît 1739 fois) et le second (qui apparait 1422 
fois) : 


In[]:= BitXor[stat[[1]][[1]], stat[[2]][[1]]] 

Out[]= (0, 3, 0, 0, 0, 0, 0, 0,0, 0, 0,0, 0, 0, 0, 0, 0, 0, O, \ 
0,0,0,0,0,0,0,0,0, 0, 0,0, 0,0, 0,0, ©, 0, 0, 0, ©, 0, 0, \ 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ©, 0, 0, 0, 0, 0, 0, \ 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, 0} 


Ils ne différent que par le second octet. 


Comparons le second bloc (qui apparait 1422 fois) et le troisième (qui apparaît 1012 
fois) : 


In[]:= BitXor[stat[[2]][[1]], stat[[3]][[1]]] 

Out[]= (0, 1, 0, 0, 0,0, 0,0, 0,0, 0, 0,0, 0, 0, 0, 0, 0, 0, \ 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, 0) 


lls ne différent également que par le second octet. 


Quoiqu'il en soit, essayons d’utiliser le bloc qui apparait le plus comme une clef XOR 
et essayons de déchiffrer les quatre premiers blocs de 81 octets dans le fichier: 


In[]:= key = stat[[1]][[1]] 

Out[]= (80, 103, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, \ 
125, 107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 111, 
5, 4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 104, 119, 
8, 109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 
1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 
102, 30, 122, 2, 117) 


M ow ua PO 


In[]:= ToASCII[val ] := If[val == 0, " ", FromCharacterCode[val, "2 
& PrintableASCII"]] 


In[]:= DecryptBlockASCII[blk ] := Map[ToASCII[#] €, BitXor[key, blk]] 
In[]:= DecryptBlockASCII[blocks[[1]]] 
Out [ ]= LL LL ; LL LL ; LL LL f LL LL , LL LL P LLI LL i LLI LL > LL LL ; LL LL i LL LL E LL LL A LL \ 


" n nu n n n onu "n nu "n nu n onu n onu n onu n nu n nu "nonu nonu "n on "n \ 
, D D D , , D D , , D D , , 


" "n onu n nu "n nu "n nu n nu "nonu "n nu "nonu n nu n nu n nu "nonu n nu " \ 
, , , , , D D , , , , , 
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" n n "nonu n nu n nu "n nu "n n n nu n nu "n nu "n nu n nu n nu "n onu " N 
D , , , D , , , D , 

n" "n nu "n nu n nu n nu "nonu "n nu n nu "n nu "n nu "n onu n nu n nu "nonu " N 
, , , , , , , , D D 

" n nu n nu "n nu n nu n n n onu "non "n nu n n n nu n nu "n nu n nu 
, , , , , , , , } 


DecryptBlockASCII[blocks[[2]]] 
{" "s "eu. "HU, "ES; LL ur "Ww", "ES "E", "D", LL mie "os. N 
LL F" ; LL LL LL C" ; TRA 7 LL I" i "M" y LL E" A LL LL LL B" LL E" "A" "Rr LL S" ; LL LL j \ 


A A O A Ea "REL ME Us, MESS TRES MOSS phos pos ales N 

" " ; " " ; " " , " " , " " : " " E " " ; " " y " " ; " LL F LL u E LL u ; n LL ; " " , N 
" " , " " , " " ; " " A " " ; " " P " " d " " ; " " A " LL y LL n " LL u ; LL u ; " " n N 
" " ` " " y " " 3 " " f " " s " " $ " " ; " " ; " " ` " n 5 LL n f LL n : LL u P " " ; N 
p cp 

In[]:= DecryptBlockASCII[blocks[[3]]] 

Qut[.]2 (^ o um e E E, PR M a TRE TE YER OU So MEN 

wy Wn, Won, Wow, Wow, a oM, How, Hos Wow, Won, Wow, now n ws n N 
wom Wow, Wow, oM, oM, Hos How, Wow, Won,» Wow n ws n ws n X 
Wy 0W ons WOÀs Wow, Wow oM, oM, Hos Hoo Wow, WoW, Wow wow n ws n X 
noo WoÀs Wow, How, MM, un Hos WoW, Won, Wow n ws n ws ou X 
Wy Mons WOÀs Wow, Wow o MOM, How, Hos Wow, Won, Wow n ws n ws n X 
"} 


DecryptBlockASCII[blocks[[4]]] 
{" ae E "HU, "o", LL ws "K^, "NU, "o", "Ww", "S LL em N 
"y" ; "HU ; "A" j "T^ ; LL LL LL E" a "y" ; LL I LL A LL fen ; LL LL LL L" ; "Uy" i LL R" À "kK" A 


, , N 
ge , E E , "I" , "N" , B B , Te , "H" , “E” , E " , "H" , "ES , "A" , "R" , ES , N 
"S" , 2 al , "o" , E , à B , "M" , ^ E" , "N" , E ?" , D x , y 7 , E y , E E , N 
E E , o E , D s , E 5 , E 5 , E B , ^f b , Ñ = , i n , " T , h " , " E , " a , d E , N 
B ^ , T ý , T à L 7 E , $ y , 3 " , 3 E , Y T , T T , y ^ , Y " , " n , " " , x T , N 


(J'ai remplacé les caractéres non imprimables par «? ».) 


Donc nous voyons que le premier et le troisiéme blocs sont vides (ou presque vide), 
mais le second et le quatrieme comportent clairement des mots/phrases en anglais. 
lls semble que notre hypothèse à propos de la clef soit correct (au moins en partie). 
Cala signifie que le bloc de 81 octets qui apparaît le plus souvent dans le fichier peut 
étre trouvé à des endroits comportant des séries d'octets à zéro ou quelque chose 
comme ca. 


Essayons de déchiffrer le fichier entier: 


DecryptBlock[blk ] := BitXor[key, blk] 
decrypted = Map[DecryptBlock[£] €, blocks]; 
BinaryWrite["/home/dennis/.../tmp", Flatten[decrypted]] 


Close["/home/dennis/.../tmp"] 
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3*E-book/decrupt dat file/tmp 4811/1628K B 
ITE NEED IO A ee ETS eHE.WEED. OF 


pp THE. HEART - o ao ai ERE ELE TE Y. 
Pra JRR. ON. MY.D ORA EE ERROR a NS ME ILE QUE 


Ed aR WEE ca aan wo ae . POS ONING.IS.relative.RND.NOT.absolute..... 


DE MEO HEN SH PUE REDE e o 
SEEMING. TO. ce. WLORT. IN. THE. AIR. 


THE FADES INTO.........EHE.SPR DARK iN, 
RR T MEME SM Med IN UNE 


Fig. 9.9: Fichier déchiffré dans Midnight Commander, 1er essai 


Ceci ressemble a des sortes de phrases en anglais d'un jeu, mais quelque chose 
ne va pas. Tout d'abord, la casse est inversée: les phrases et certains mots com- 
mence avec une minuscule, tandis que d'autres caractéres sont en majuscule. De 
plus, certaines phrases commencent avec une mauvaise lettre. Regardez la toute 
premiére phrase: «eHE WEED OF CRIME BEARS BITTER FRUIT ». Que signifie «eHE » ? 
Ne devrait-on pas avoir «tHE » ici? Est-il possible que notre clef de déchiffrement ait 
un mauvais octet à cet endroit? 


Regardons à nouveau le second bloc dans le fichier, la clef et le résultat décrypté: 


In[]:= blocks[[2]] 

Out[]= (80, 2, 74, 49, 113, 49, 51, 92, 39, 8, 92, 81, 116, 62, \ 

57, 80, 46, 40, 114, 36, 75, 56, 33, 76, 9, 55, 56, 59, 81, 65, 45, \ 
28, 60, 55, 93, 39, 90, 28, 124, 106, 16, 20, 104, 119, 8, 109, 26, \ 
106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 1, 126, 29, \ 
97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 102, 30, \ 
122, 2, 117) 


In[]:= key 

Out[]= (80, 103, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, \ 

125, 107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 111, \ 
5, 4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 104, 119, \ 
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8, 109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, \ 
1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, \ 
102, 30, 122, 2, 117} 


In[]:= BitXor[key, blocks[[2]]] 

Out[]= (0, 101, 72, 69, 0, 87, 69, 69, 68, O, 79, 70, 0, 67, 82, \ 

73, 77, 69, 0, 66, 69, 65, 82, 83, 0, 66, 73, 84, 84, 69, 82, 0, 70, \ 
82, 85, 73, 84, 14, 0, 0, 0, 06,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ 
0, 0, 0, 0) 


L'octet chiffré est 2, l'octet de la clef est 103, 2€ 103 = 101 et 101 est le code ASCII 
du caractère «e ». A quoi devrait être égal l'octet de la clef, afin que le code ASCII 
résultant soit 116 (pour le caractére «t »)? 26116 = 118, mettons 118 comme second 
octet de la clef ... 


key = (80, 118, 2, 116, 113, 102, 118, 25, 99, 8, 19, 23, 116, 125, 
107, 25, 99, 109, 114, 102, 14, 121, 115, 31, 9, 117, 113, 111, 5, 
4, 127, 28, 122, 101, 8, 110, 14, 18, 124, 106, 16, 20, 104, 119, 8, 

109, 26, 106, 9, 97, 13, 99, 15, 119, 20, 105, 117, 98, 103, 118, 
1, 126, 29, 97, 122, 17, 15, 114, 110, 3, 5, 125, 125, 99, 126, 119, 
102, 30, 122, 2, 117} 


...et déchiffrons le fichier à nouveau. 


A ee ee WEM MUERE EE tHE.WEED. OF 
. CRIME. BEARS. BITTER. FRUIT 


. OF. THE. UNDEAD. . VAMPIR 
A FILLING asi 


.R. SINISTER. . HRRITHLIKE.FI 
iN.R.LOH. . SORROHFUL . VOI CE.H 
. «AND, THE. DUNGEON. CANNOT. BE. FOUND. . , aLL.. : 
FEGTBCEBIBHAELIC, HE EBDES EH TU S urn TH RERDING.D cho ae LE. 25. A. TAS 
LEY- LETTERED: SEM canoas ALU RE PR O E 


Fig. 9.10: Fichier déchiffré dans Midnight Commander, 2nd essai 


Ouah, maintenant, la grammaire est correcte, toutes les phrases commencent avec 
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une lettre correcte. Mais encore, l'inversion de la casse est suspecte. Pourquoi est- 
ce que le développeur les aurait écrites de cette facon? Peut-étre que notre clef est 
toujours incorrecte? 


En regardant la table ASCII, nous pouvons remarquer que les codes des lettres ma- 
juscules et des minuscules ne différent que d'un bit (6ème bit en partant de 1, 
0b100000) : 


Fig. 9.11: table ASCII 7-bit dans Emacs 


Cet octet avec seul le 6éme bit mis est 32 au format décimal. Mais 32 est le code 
ASCII de l'espace! 


En effet, on peut changer la casse juste en XOR-ant le code ASCII d'un caractére 
avec 32 (plus à ce sujet: 3.19.3 on page 691). 


Est-ce possible que les parties vides dans le fichier ne soient pas des octets à zéro, 
mais plutót des espaces? Modifions notre clef XOR encore une fois (je vais appliquer 
Un XOR avec 32 à chaque octet de la clef) : 


(* "32" is scalar and "key" is vector, but that's OK *) 


In[]:= key3 = BitXor[32, key] 

Out[]= (112, 86, 34, 84, 81, 70, 86, 57, 67, 40, 51, 55, 84, 93, 75, \ 
57, 67, 77, 82, 70, 46, 89, 83, 63, 41, 85, 81, 79, 37, 36, 95, 60, \ 
90, 69, 40, 78, 46, 50, 92, 74, 48, 52, 72, 87, 40, 77, 58, 74, 41, \ 
65, 45, 67, 47, 87, 52, 73, 85, 66, 71, 86, 33, 94, 61, 65, 90, 49, \ 
47, 82, 78, 35, 37, 93, 93, 67, 94, 87, 70, 62, 90, 34, 85) 


In[]:= DecryptBlock[blk ] := BitXor[key3, blk] 


Déchiffrons á nouveau le fichier d'entrée: 
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/ home/dennis/P/RE-book/decrupt dat file/tmp3 


Fig. 9.12: Fichier déchiffré dans Midnight Commander, essai final 


(Le fichier déchiffré est disponible ici.) 


Ceci est indiscutablement un fichier source correct. Oh, et nous voyons des nombres 
au début de chaque bloc. Ca doit étre la source de notre clef XOR erronée. Il semble 
que le bloc de 81 octets le plus fréquent dans le fichier soit un bloc rempli avec des 
espaces et contenant le caractére «1» à la place du second octet. En effet, d'une 
facon ou d'une autre, de nombreux blocs sont entrelacés avec celui-ci. 


Peut-étre est-ce une sorte de remplissage pour les phrases/messages courts? D'autres 
blocs de 81 octets sont aussi remplis avec des blocs d'espaces, mais avec un chiffre 
différent, ainsi, ils ne différent que du second octet. 


C'est tout! Maintenant nous pouvons écrire un utilitaire pour chiffrer à nouveau le 
fichier, et peut-étre le modifier avant. 


Le fichier notebook de Mathematica est téléchargeable 


Résumé: un tel chiffrement avec XOR n'est pas robuste du tout. Le développeur du 
jeu escomptait, probablement, empécher les joueurs de chercher des informations 
sur le jeu, mais rien de plus sérieux. Néanmoins, un tel chiffrement est trés popu- 
laire du fait de sa simplicité et de nombreux rétro-ingénieurs sont traditionnellement 
familier avec. 
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9.1.5 Chiffrement simple utilisant un masque XOR, cas Il 


J'ai un autre fichier chiffré, qui est clairement chiffré avec quelque chose de simple, 
comme un XOR: 


/home/denni s/tmp/cipher.txt Bx«aaaannnaa 
SERCCCDCCMDE 
46088018 
46888628 
46600638 
4a888848 
46680858 
VBBBAB6A 
46088078 
VBBBABEa 
LUTTE 
VBBBABAD 
VBBBBBBA 
VBBBBBCO 
VBBBABDA 
PBBBABEA 
DBBBABFa 
46666168 
46060110 
46060120 
46060138 
46460148 
46060156 
46080168 
446001 78 
46080188 
46080198 
460801AB 
VBBBB1BA 
46080108 
VBBBB1DA 
VBBBB1EO 
460001F 8 


Fig. 9.13: Fichier chiffré dans Midnight Commander 


Le fichier chiffré peut étre téléchargé 


L'utilitaire Linux ent indique environ ~7.5 bits par octet, et ceci est un haut niveau 
d’entropie ( ), proche de celui de fichiers compressés ou chiffrés 
correctement. Mais encore, nous distinguons clairement quelques patterns, il y a 
quelques blocs avec une taille de 17 octets, et nous pouvons voir des sortes d’échelles, 
se décalant d’un octet a chaque ligne de 16 octets. 


On sait aussi que le texte clair est en anglais. 


Maintenant, supposons que ce morceau de texte est chiffré par un simple XOR avec 
une clef de 17 octets. 
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J'ai essayé de repérer des blocs de 17 octets se répétant avec Mathematica, comme 
je l'ai fait dans l'exemple précédant (9.1.4 on page 1209) : 


Listing 9.3 : Mathematica 


In[]:=input = BinaryReadList["/home/dennis/tmp/cipher.txt"]; 
In[]:=blocks = Partition[input, 17]; 
In[]:=Sort[Tally[blocks], £1[[21] > #2[[2]] 4] 


Out[]1:={{{248,128,88,63,58,175,159,154,232,226,161,50,97,127,3,217,80},1}, 
{{226,207,67,60,42,226,219,150,246,163,166,56,97,101,18,144,82},1}, 
{{228,128,79,49,59,250,137,154,165,236,169,118,53,122,31,217,65},1}, 
{{252,217,1,39,39,238,143,223,241,235,170,91,75,119,2,152,82},1}, 
{{244,204,88,112,59,234,151,147,165,238,170,118,49,126,27,144,95},1}, 
{{241,196,78,112,54,224,142,223,242,236,186,58,37,50,17,144,95},1}, 
{{176,201,71,112,56,230,143,151,234,246,187,118,44,125,8,156,17},1}, 


{{255,206,82,112,56,231,158,145,165,235,170,118,54,115,9,217,68},1}, 
{{249,206,71,34,42, 254,142,154, 235, 247, 239,57,34,113,27,138,88},1}, 
{{157,170,84,32,32,225,219,139,237,236,188,51,97,124,21,141,17},1}, 
{{248,197,1,61,32,253,149,150,235,228,188,122,97,97,27,143,84},1}, 

{{252,217,1,38,42,253,130,223,233,226,187,51,97,123,20,217,69},1}, 

{{245,211,13,112,56,231,148,223,242,226,188,118,52,97,15,152,93},1}, 
{{221,210,15,112,28,231,158,141,233,236,172,61,97,90,21,149,92},1}} 


Pas de chance, chaque bloc de 17 octets est unique dans le fichier, et n'apparait donc 
qu'une fois. Peut-étre n’y a-t-il pas de zone de 17 octets a zéro, ou de zone contenant 
seulement des espaces. C’est possible toutefois: de telles séries d’espace peuvent 
étre absentes dans des textes composés rigoureusement. 


La premiére idée est d’essayer toutes les clefs de 17 octets possible et trouver celles 
qui donnent un résultat lisible aprés déchiffrement. La force brute n’est pas une 
option, car il y a 256!” clefs possible (~10*°), c'est beaucoup trop. Mais il y a une bonne 
nouvelle: qui a dit que nous devons tester la clef de 17 octets en entier, pourquoi ne 
pas teste chaque octet séparémment? C’est possible en effet. 


Maintenant, l'algorithme est: 
* essayer chacun des 25 octets pour le premier octet de la clef; 
* déchiffrer le ler octet de chaque bloc de 17 octets du fichier; 
* est-ce que tous les octets déchiffrés sont imprimable? garder un oeil dessus; 
* faire de méme pour chacun des 17 octets de la clef. 


J'ai écrit le script Python suivant pour essayer cette idée: 


Listing 9.4 : Python script 


each Nth byte-[""]*KEY LEN 


content-read file(sys.argv[1]) 
# split input by 17-byte chunks: 
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all_chunks=chunks (content, KEY_LEN) 
for c in all_chunks: 
for i in range(KEY LEN): 
each Nth byte[i]zeach Nth byte[i] + c[i] 


# try each byte of key 
for N in range(KEY LEN): 
print "N=", N 
possible keys=[] 
for i in range(256): 
tmp keyschr(i)*len(each Nth byte[N]) 
tmp-xor strings(tmp key,each Nth byte[N]) 
# are all characters in tmp[] are printable? 
if is string printable(tmp)--False: 
continue 
possible keys.append(i) 
print possible keys, "len=", len(possible keys) 


(La version compléte du code source est ici.) 


Voici sa sortie: 


N= 0 

[144, 145, 151] len= 3 
N= 1 

[160, 161] len= 2 
N= 2 

[32, 33, 38] len= 3 
N= 3 

[80, 81, 87] len= 3 
N= 4 

[78, 79] len= 2 

N= 5 

[142, 143] len= 2 
N= 6 

[250, 251] len= 2 
N= 7 

[254, 255] len= 2 
N= 8 

[130, 132, 133] len= 3 
N= 9 

[130, 131] len= 2 
N= 10 

[206, 207] len= 2 
N= 11 

[81, 86, 87] len= 3 
N= 12 

[64, 65] len= 2 

N= 13 

[18, 19] len= 2 

N= 14 

[122, 123] len= 2 
N= 15 

[248, 249] len= 2 
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N= 16 
[48, 49] len= 2 


Donc, il y a 2 ou 3 octets possible pour chaque octet de | clef de 17 octets. C'est 
mieux que 256 octets pour chaque octet, mais encore beaucoup trop. ll y a environ 
1 million de clefs possible: 


Listing 9.5 : Mathematica 
In[] := 3*2*3*3*2*2*2*2*3*2*2*3*2*2*2*2*2 
Out[]= 995328 


Il est possible de les vérifier toutes, mais alors nous devons vérifier visuellement si 
le texte déchiffré à l'air d'un texte en anglais. 


Prenons en compte le fait que nous avons a faire avec 1) un langage naturel 2) 
de l'anglais. Les langages naturels ont quelques caractéristiques statistiques impor- 
tantes. Tout d’abord, le ponctuation et la longueur des mots. Quelle est la longueur 
moyenne des mots en anglais? Comptons les espaces dans quelques textes bien 
connus en anglais avec Mathematica. 


Voici le fichier texte de «The Complete Works of William Shakespeare » provenant de 
la bibliotheque Gutenberg. 


Listing 9.6 : Mathematica 


In[]:= input = BinaryReadList["/home/dennis/tmp/pg100.txt"]; 
In[]:= Tally[input] 
Out[]= {{239, 1), (187, 1), (191, 1}, (84, 39878}, (104, 


218875}, {101, 406157}, {32, 1285884}, {80, 12038}, {114, 

209907}, {111, 282560}, {106, 2788}, {99, 67194}, {116, 

291243}, {71, 11261}, {117, 115225}, {110, 216805}, {98, 

46768}, {103, 57328}, {69, 42703}, {66, 15450}, {107, 29345}, {102, 

69103}, {67, 21526}, {109, 95890}, {112, 46849}, {108, 146532}, {87, 
16508}, {115, 215605}, {105, 199130}, {97, 245509}, {83, 

34082}, {44, 83315}, {121, 85549}, {13, 124787}, {10, 124787}, {119, 
73155}, {100, 134216}, {118, 34077}, {46, 78216}, {89, 9128}, {45, 

8150}, {76, 23919}, {42, 73}, {79, 33268}, {82, 29040}, {73, 

55893}, {72, 18486}, {68, 15726}, {58, 1843}, {65, 44560}, {49, 

982}, {50, 373}, {48, 325}, {91, 2076}, {35, 3}, {93, 2068}, {74, 
2071}, {57, 966}, {52, 107}, {70, 11770}, {85, 14169}, {78, 

27393}, {75, 6206}, {77, 15887}, {120, 4681}, {33, 8840}, {60, 

468}, {86, 3587}, {51, 343}, {88, 608}, {40, 643}, {41, 644}, {62, 
440}, {39, 31077}, {34, 488}, {59, 17199}, {126, 1}, {95, 71}, {113, 
2414}, {81, 1179}, {63, 10476}, {47, 48}, {55, 45}, {54, 73}, {64, 
3}, {53, 94}, {56, 47}, {122, 1098}, {90, 532}, {124, 33}, {38, 

21}, {96, 1}, {125, 2}, {37, 1}, {36, 2}} 


In[]: 
Out[] 


Length[input]/1285884 // N 
4.34712 


Il y a 1285884 espaces dans l'ensemble du fichier, et la fréquence de l'occurrence 
des espaces est de 1 par -4.3 caracteres. 
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Maintenant voici Alice's Adventures in Wonderland, par Lewis Carroll de la méme 
bibliotheque: 


Listing 9.7 : Mathematica 


In[]:= input = BinaryReadList["/home/dennis/tmp/pgl1.txt"]; 
In[]:= Tally[input] 
Out[]= (1239, 1), (187, 1), (191, 1), (80, 172), (114, 6398}, (111, 


9243), 1106, 222), (101, 15082), (99, 2815), (116, 11629), (32, 
27964), (71, 193}, (117, 3867), (110, 7869), (98, 1621}, (103, 
2750), (39, 2885), (115, 6980), (65, 721), (108, 5053), (105, 

7802}, (100, 5227}, (118, 911), (87, 256), (97, 9081}, (44, 

2566), (121, 2442}, (76, 158), (119, 2696}, (67, 185}, (13, 

3735), (10, 3735}, (84, 571), (104, 7580}, (66, 125}, (107, 

1202), (102, 2248), (1109, 2245}, (46, 1206), (89, 142}, (112, 
1796}, (45, 744}, (58, 255), (68, 242}, (74, 13), (50, 12), (53, 
13), (48, 22), (56, 10}, (91, 4), (69, 313}, (35, 1}, (49, 68}, (93, 
4}, (82, 212}, (77, 222), 157, 11}, (52, 10}, (42, 88}, (83, 

288), 179, 234}, (70, 134}, (72, 309}, (73, 831), (85, 111), (78, 
182), (75, 88), (86, 52), (51, 13), (63, 202), (40, 76), (41, 

76}, (59, 194}, (33, 451}, (113, 135}, (120, 170}, (90, 1), (122, 
79}, (34, 135}, (95, 4), (81, 85), (88, 6), (47, 24}, 155, 6}, (54, 
7}, (37, 1}, {64, 2), (36, 2}} 


In[]:= Length[input]/27964 // N 
Out[]= 5.99049 


Le résultat est différent, sans soute a cause d’un formatage des textes différents 
(indentation ou remplissage). 


Ok, donc supposons que la fréquence moyenne de l'espace en anglais est de 1 es- 
pace tous les 4..7 caractéres. 


Maintenant, encore une bonne nouvelle: nous pouvons mesurer la fréquence des 
espaces au fur et à mesure du déchiffrement de notre fichier. Maintenant je compte 
les espaces dans chaque slice et jette les clefs de 1 octets qui produise un résultat 
avec un nombre d'espaces trop petit (ou trop grand, mais c'est presque impossible 
avec une si petite clef) : 


Listing 9.8 : Python script 


each Nth byte-[""]*KEY LEN 


content-read file(sys.argv[1]) 
# split input by 17-byte chunks: 
all_chunks=chunks (content, KEY LEN) 
for c in all chunks: 
for i in range(KEY LEN): 
each Nth_byte[i]=each Nth byte[i] + c[il 


# try each byte of key 

for N in range(KEY LEN): 
print "N=", N 
possible keys=[] 
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for i in range(256): 
tmp keyschr(i)*len(each Nth byte[N]) 


tmp-xor strings(tmp key,each Nth byte[N]) 
# are all characters in tmp[] are printable? 


if is string printable(tmp)--False: 
continue 
# count spaces in decrypted buffer: 
spaces-tmp.count(' ') 
if spaces--0: 
continue 
spaces ratio-len(tmp)/spaces 
if spaces ratio<4: 
continue 
if spaces ratio>7: 
continue 
possible keys.append(i) 


print possible keys, "len=", len(possible keys) 


(La version compléte du code source se trouve ici.) 


Ceci nous donne un seul octet possible pour chaque octet de la clef: 


N= 0 

[144] len= 1 
N= 1 

[160] len= 1 
N= 2 

[33] len= 1 

N= 3 

[80] len= 1 

N= 4 

[79] len= 1 

N= 5 

[143] len= 1 
N= 6 

[251] len= 1 
N= 7 

[255] len= 1 
N= 8 

[133] len= 1 
N= 9 

[131] len= 1 
N= 10 

[207] len= 1 
N= 11 

[86] len= 1 

N= 12 

[65] len= 1 

N= 13 

[18] len= 1 

N= 14 

[122] len= 1 
N= 15 

[249] len= 1 
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N= 16 
[49] len= 1 


Vérifions cette clef dans Mathematica: 


Listing 9.9 : Mathematica 


In[]:= input = BinaryReadList["/home/dennis/tmp/cipher.txt"]; 


In[]:= blocks = Partition[input, 17]; 


In[]:= key = (144, 160, 33, 80, 79, 143, 251, 255, 133, 131, 207, 86, 65, 
S 18, 122, 249, 49}; 


In[]:= EncryptBlock[blk ] := BitXor[key, blk] 
In[]:= encrypted = Map[EncryptBlock[#] &, blocks]; 


In[]:= BinaryWrite["/home/dennis/tmp/plain2.txt", Flatten[encrypted]] 


In[]:= Close["/home/dennis/tmp/plain2.txt"] 


2 


Et le texte brut est: 


Mr. Sherlock Holmes, who was usually very late in the mornings, save 
upon those not infrequent occasions when he was up all night, was seated 
at the breakfast table. I stood upon the hearth-rug and picked up the 
stick which our visitor had left behind him the night before. It was a 
fine, thick piece of wood, bulbous-headed, of the sort which is known as 
a "Penang lawyer." Just under the head was a broad silver band nearly 

an inch across. "To James Mortimer, M.R.C.S., from his friends of the 
C.C.H.," was engraved upon it, with the date "1884." It was just such a 
stick as the old-fashioned family practitioner used to carry--dignified, 
solid, and reassuring. 


"Well, Watson, what do you make of it?" 


Holmes was sitting with his back to me, and I had given him no sign of 
my occupation. 


(La version compléte de ce texte se trouve ici.) 


Le texte semble correct. Oui, j'ai créé cet exemple de toutes piéces et j'ai choisi un 
texte trés connu de Conan Doyle, mais c'est trés proche de ce que j'ai eu à faire il y 


a quelques temps. 


Autres idées à envisager 


Si nous échouions avec le comptage des espaces, il y a d'autres idées à essayer: 


* Prenons en considération le fait que les lettres minuscules sont plus fréquentes 


que celles en majuscule. 
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* Analyse des fréquences. 


* || y a aussi une bonne technique pour détecter le langage d'un texte: les tri- 
grammes. Chaque langage possède des triplets de lettres fréquences, qui peuvent 
étre «the» et «tha» en anglais. En lire plus à ce sujet: N-Gram-Based Text 
Categorization, http://code.activestate.com/recipes/326576/. Fait suffi- 
samment intéressant, la détection des trigrammes peut étre utilisée lorsque 
vous décryptez un texte chiffré progressivement, comme dans cet exemple 
(yous devez juste tester les 3 caracteres décryptez adjacents). 


Pour les systémes non-latin encodés en UTF-8, les choses peuvent étre plus 
simples. Par exemple, les textes en russe encodés en UTF-8 ont chaque octet 
intercalé avec des octets OxD0/0xD1. C'est parce que les caracteres cyrilliques 
sont situés dans le 4éme bloc de la table Unicode. D'autres systémes d'écriture 
on leurs propres blocs. 


9.1.6 Devoir 


Un ancien jeu d'aventure en texte pour MS-DOS, développé à la fin des années 1980. 
Pour cacher les informations du jeu aux joueurs, les fichiers de données sont, le plus 
probablement, XORé avec quelque chose: https://beginners.re/homework/XOR _ 
crypto l/destiny.zip. Essayez d'y rentrer... 


9.2 Information avec l'entropie 


Entropy: The quantitative measure of 
disorder, which in turn relates to the 
thermodynamic functions, temperature, and 
heat. 


Dictionaire: Applied Math for Engineers and 
Scientists 


Par soucis de simplification, je dirais que l'entropie est une mesure, d'à quel point des 
données peuvent étre compressées. Par exemple, il est généralement impossible de 
compresser un fichier archive déjà compressé, donc il a une entropie importante. 
D'un autre coté, 1MiB d'octet à zéro peut étre compressé en un tout petit fichier. 
En effet, en francais, un million de zéro peut étre simplement décrit par "le fichier 
résultant est un million d'octets à zéro". Les fichiers compressés sont en général une 
liste d'instructions destinées au dé-compresseur, comme ceci: "mettre 1000 zéros, 
puis l'octet 0x23, puis l'octet 0x45, puis un bloc d'une taille de 10 octets que nous 
avons vu 500 octets avant, etc." 


Les textes écrits en langage naturel peuvent aussi étre fortement compressés, car le 
langage naturel a beaucoup de redondance (autrement, une petite typo conduirait 
toujours à une incompréhension, comme un bit inversé dans un fichier archive rend 
la décompression presque impossible), certains mots sont utilisés trés souvent, etc. 
Dans le discours courant, il est possible de supprimer jusqu'à la moitié des mots et 
il est toujours compréhensible. 
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Le code pour les CPUs peut aussi étre compressé, car certaines instructions ISA sont 


utilisées plus souvent que d'autres. En x86, les instructions les plus utilisées sont 
MOV/PUSH/CALL (5.11.2 on page 951). 


La compression de données et le chiffrement tendent à produire des résultats avec 
une trés haute entropie. Un bon PRNG produit aussi des données qui ne peuvent pas 
étre compressées (il est possible de mesurer leur qualité par ce moyen). 


Donc, autrement dit, la mesure de l'entropie peut aider à tester le contenu de bloc 
de données inconnues. 


9.2.1 Analyse de l'entropie dans Mathematica 


(Cette partie est parue initialement sur mon blog le 13 mai 2015. Quelques discus- 
sions: https://news.ycombinator.com/item?id=9545276.) 


Il est possible de découper un fichier par blocs, de calculer l'entropie de chacun 
d'eux et de dessiner un graphe. J'ai fais ceci avec Wolfram Mathematica à titre de 
démonstration et voici le code source (Mathematica 10) : 


(* loading the file *) 
input-BinaryReadList["file.bin"]; 


(* setting block sizes *) 
BlockSize=4096;BlockSizeToShow=256; 


(* slice blocks by 4k *) 
blocks=Partition[input,BlockSize]; 


(* how many blocks we've got? *) 
Length[blocks] 


(* calculate entropy for each block. 2 in Entropy[] (base) is set with the 7 
& intention so Entropy[] 

function will produce the same results as Linux ent utility does *) 

entropies-Map[N[Entropy[2,2]]&, blocks]; 


(* helper functions *) 

fBlockToShow[input_,offset_]:=Take[input,(l+offset,1l+offset+BlockSizeToShow 
V H 

fToASCII[val_]:=FromCharacterCode[val,"PrintableASCII"] 

fToHex[val_]:=IntegerString[val,16] 

fPutASCIIWindow[data ]:-Framed[Grid[Partition[Map[fTOASCII,data],16]]] 

fPutHexWindow[data ]:-Framed[Grid[Partition[Map[fToHex, data], 16], ALignment 7 
y ->Right]] 


(* that will be the main knob here *) 
{Slider [Dynamic[offset] ,{0,Length[input] -BlockSize, BlockSize}] ,Dynamic[ 7 
V BaseForm[offset,16] ]} 


(* main UI part *) 

Dynamic[{ListLinePlot [entropies ,GridLines->{{-1,offset/BlockSize,1}},v 
y Filling->Axis ,AxesLabel->{"offset","entropy"}], 

CurrentBlock=fBlockToShow[input offset]; 
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fPutHexWindow[CurrentBlock], 
fPutASCIIWindow[CurrentBlock] }] 


Base de données GeolP de FAI 


Commencons avec le fichier GeoIP (qui assigne un FAI au bloc d'adresses IP). Ce fi- 
chier binaire GeolPISP.dat a plusieurs tables (qui sont peut-être les intervalles d'adresses 
IP) plus quelques blobs de texte à la fin du fichier (contenant les noms des FAI). 


Lorsque je le charge dans Mathematica, je vois ceci: 


In[88]= (+ that will be the main knob here +) 


(Slider[Dynamic[offset], (0, Length[input] - BlockSize, BlockSize)] 


r 


Ourjes]= | , £700016) 


In[59:= (+ main UI part + 
Dynamic[(ListLinePlot[entropies, GridLines > ((-1, offset / BlockSiz 
CurrentBlock = fBlockToShow [ input, offset]: 
fPutHexWindow[CurrentBlock], fPutASCIIWindow [CurrentBlock] }] 


entropy 


Out[59= | 
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Il y a deux parties dans le graphe: la premiére est un peu chaotique, la seconde est 
plus réguliére. 


0 sur l'axe vertical du graphe signifie l'entropie la plus basse (les données qui peuvent 
étre compressée trés fortement, ordonnées en d'autres mots) et 8 est la plus haute 
(ne peuvent pas étre compressées du tout, chaotique ou aléatoires en d'autres mots). 
Pourquoi O et par 8? 0 signifie O bits par octet (l'octet en tant que conteneur n'est 
pas rempli du tout) et 8 signifie 8 bits par octet, i.e., l'octet comme conteneur est 
complétement rempli d'information. 


Donc, je mets le curseur pour pointer sur le milieu du premier bloc, et je vois clai- 
rement des tableaux d'entiers 32-bit. Maintenant je mets le curseur au milieu du 
second bloc et je vois un texte en anglais: 


Inf68}= (+ that will be the main knob here +) 
(Slider[Dynamic[offset], (0, Length[input] - BlockSize, BlockSize)] 


OuteS]- | , 26400016 i 


Inf59}= (+ main UI part 
Dynamic[{ListLinePlot[entropies, GridLines > ((-1, offset /BlockSiz 


CurrentBlock = fBlockToShow[input, offset]: 
fPutHexWindow[CurrentBlock], fPutASCIIWindow [CurrentBlock])] 


entropy 


Outss | 
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En effet, ceci sont les noms des FAls. Donc, l'entropie de textes en anglais est 4.5- 
5 bits par octet? Oui, quelque chose comme ca. Wolfram Mathematica comprend 
quelques corpus de littérature anglaise bien connu, et nous pouvons voir l'entropie 
de sonnets de Shakespeare: 


In[]:= Entropy[2,ExampleData[{"Text", "ShakespearesSonnets"}]]//N 
Out[]= 4.42366 


4,4 est proche de ce que nous obtenons ()4.7-5.3). Bien sûr, les textes de la litté- 
rature anglaise classique sont quelques peu différents des noms des FAls et autres 
texte en anglais que nous pouvons trouver dans des fichiers binaires (débogage/tra- 
ce/messages d’erreur), mais cette valeur est proche. 

Firmware TP-Link WR941 


Pour l'exemple suivant, j'ai pris le firmware du routeur TP-Link WR941: 


entropy 


Nous voyons ici 3 blocs avec des vides. Puis le premier bloc avec une haute entropie 
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(démarrant a l'adresse 0) est petit, le second (adresse quelque part en 0x22000) et 
plus grand et le troisiéme (adresse 0x123000) est le plus grand. Je ne peux pas étre 
certain de l'entropie du premier bloc, mais le 2-ème et le 3-ème ont une entropie 
trés haute, signifiant que ces blocs sont soit compressés et/ou chiffrés. 


J'ai essayé binwalk pour ce fichier de firmware: 


DECIMAL HEXADECIMAL DESCRIPTION 
S 

0 0x0 TP-Link firmware header, firmware version: 7 
& 0.-15221.3, image version: "", product ID: 0x0, product version: 2 


V 155254789, kernel load address: 0x0, kernel entry point: Ox-7FFFE000,2 
Y kernel offset: 4063744, kernel length: 512, rootfs offset: 837431, 7 
y rootfs length: 1048576, bootloader offset: 2883584, bootloader length” 


V: 0 

14832 0x39F0 U-Boot version string, "U-Boot 1.1.4 (Jun 27 2 
& 2014 - 14:56:49)" 

14880 0x3A20 CRC32 polynomial table, big endian 

16176 0x3F30 ulmage header, header size: 64 bytes, header 7 


CRC: 0x3AC66E95, created: 2014-06-27 06:56:50, image size: 34587 7 

y bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 07 
\ xDF2DBAOB, OS: Linux, CPU: MIPS, image type: Firmware Image, 2 

y compression type: lzma, image name: "u-boot image" 


16240 Ox3F70 LZMA compressed data, properties: 0x5D, 2 
G dictionary size: 33554432 bytes, uncompressed size: 90000 bytes 
131584 0x20200 TP-Link firmware header, firmware version: 2 
& 0.0.3, image version: "", product ID: 0x0, product version: 2 


V 155254789, kernel load address: 0x0, kernel entry point: Ox-7FFFE000,2 
V kernel offset: 3932160, kernel length: 512, rootfs offset: 837431, 2 
y rootfs length: 1048576, bootloader offset: 2883584, bootloader length” 


V: 
132096 0x20400 LZMA compressed data, properties: 0x5D, 2 

y dictionary size: 33554432 bytes, uncompressed size: 2388212 bytes 
1180160 0x120200 Squashfs filesystem, little endian, version 7 


S 4.0, compression:lzma, size: 2548511 bytes, 536 inodes, blocksize: 7 
S 131072 bytes, created: 2014-06-27 07:06:52 


En effet: il y a des choses au début, mais deux larges blocs compressés LZMA com- 
mencent en 0x20400 et 0x120200. Ce sont en gros les adresses que nous avons vu 
dans Mathematica. Oh, à propos, binwalk peut aussi afficher l'entropie (option -E) : 


DECIMAL HEXADECIMAL ENTROPY 
S 

0 0x0 Falling entropy edge (0.419187) 
16384 0x4000 Rising entropy edge (0.988639) 

51200 0xC800 Falling entropy edge (0.000000) 
133120 0x20800 Rising entropy edge (0.987596) 

968704 OxEC800 Falling entropy edge (0.508720) 
1181696 0x120800 Rising entropy edge (0.989615) 


3727360 0x38E000 Falling entropy edge (0.732390) 
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Les fronts ascendants correspondent a des fronts ascendants de blocs sur notre 
graphe. Les fronts descendants sont des points oü des espaces vides commencent. 


Binwalk peut aussi générer un graphe PNG (-E -J): 


Que pouvons-nous dire à propos de ces espaces vides? En regardant dans un édi- 
teur hexadécimal, nous voyons qu'ils sont simplement remplis avec des octets à 
OxFF. Pourquoi les développeurs les ont-ils mises? Peut-étre parce qu'ils n'ont pas 
pu calculer précisément la taille des blocs compressés, et leurs ont donc alloué de 
l'espace avec une marge. 


Notepad 


Un autre exemple est notepad.exe que j'ai pris dans Windows 8.1: 
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Inf72;= (+ that will be the main knob here x) 
fSlider[Dynamic[offset], (0, Length[input] - BlockSize, BlockSize)], 


Ou | : 1900016} 


sort reverse © & [E] 


In[s9= (+ main UI part +) 
Dynamic[{ListLinePlot[entropies, GridLines > {{-1, offset /BlockSiz 
CurrentBlock = fBl1lockToShow [ input, offset]; 
fPutHexWindow[CurrentBlock], fPutASCIIWindow[CurrentBlock])] 


entropy 


B 
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Il y a un creux a x 0219000 (offset absolu dans le fichier). J'ai ouvert le fichier exé- 
cutable dans un éditeur hexadécimal et trouvé des tables d'imports (qui ont une 
entropie plus basse que le code x86-64 dans la première moitié du graphe). 


Il y a aussi un bloc avec une grande entropie qui démarre « 0220000 : 
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In[72]:= 


ougz- | , 2000016} 


sort reverse e EJ 


In[jss: (+ main UI part +) 
Dynamic[(ListLinePlot[entropies, GridLines > ((-1, offset/BlockSiz 
CurrentBlock - fBlockToShow[input, offset]: 
fPutHexWindow [CurrentBlock], fPutASCIIWindow [CurrentBlock])] 


entropy 
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Dans un éditeur hexadécimal je peux y voir un fichier PNG, inséré dans la section 
ressource du fichier PE (c'est une grosse image de l'icône de notepad). Les fichiers 
PNG sont compressés, en effet. 


Dashcam sans marque 


Maintenant l'exemple le plus avancé dans cette partie est le firmware d'une dashcam 
sans marque que j'ai recu d'un ami: 


1234 
Inf63];= (+ that will be the main knob here + 


(Slider[Dynamic[offset], (0, Length[input] - BlockSize, BlockSize}], 
owes | f 3400016} 


sort reverse © m EJ 
In[s9= (+ main UI part + 
Dynamic[(ListLinePlot[entropies, GridLines > {{-1, offset / BlockSiz: 
CurrentBlock = fBlockToShow [input, offset]: 
fPutHexWindow [CurrentBlock], fPutASCIIWindow [CurrentBlock] }] 


entropy 

8.0 

= 

7.0 
Out¡s9= 195 

6.0 

55 

5.0 

A offset 

0 100 200 200 400 500 600 
44 5f 53 50 49 5f 46 57 32 0 0 0 53 45 4449] [D_SPI_FW2O000SEMI 
44 5f 53 50 49 5f 46 57 33 0 0 0 53 45 4449] |D S PI FW3D0ODSEMI 
44 5f 53 50 49 5f 50 53 0 0 0 0 53 45 4d 49 |D_SPI_PSOOOOSEMI 
44 5f 53 50 49 5f 50 53 32 0 0 0 53 45 4d 49| D SPI PS200DSEMI 
44 5f 53 50 49 5f 50 53 33 0 0 0 53 45 4d 49 |D_SPI_PS3000SEMI 
44 5f 53 50 49 5f 46 41 54 0 0 0 53 45 4d 49] [D-SPI_FATODOSEMI 
44 5f 53 50 49 5f 46 41 54 32 0 0 53 45 4d 49| D SPI FAT20DSEMI 
44 5f 53 50 49 SE 46 41 54 33 0 0 Se 5225 73 |D SPI FATSDDH^RSSsj, 
'|3a 3a 25 73 28 29 3a 25 64 2d 45 52 52 3a 20 25/ &s():5d-ERR: 2l 
73 3a 20 53 65 6e 4d 6f 64 65 28 25 64 29 20 6£| |s SenMode(*d)J o 
75 74 20 6f 66 20 72 61 6e 67 65 21 21 21 d a||ut of range!!! 
0 0 0 0 41 52 30 33 33 30 0 0 Se 5225 73|  DDGBDBAR O3 30D D^ R $ s 
3a 3a 25 73 28 29 3a 25 64 2d 45 52 52 3a 20 45 £s5():d-ERR: E 
72 72 6f 72 20 74 72 61 6e 73 6d 69 74 20 64 61| lrror transmit da 
74 61 20 28 77 72 69 74 65 20 61 64 64 72 29 21| |ta (write addr): 
21 d a 0 Se 52 25 73 3a 3a 25 73 28 29 3a 25 D^R£&s::55()::5 


La creux au tout début est un texte en anglais: messages de débogage. J'ai vérifié 
différents ISAs et j'ai trouvé que le premier tiers du fichier complet (avec le segment 
de texte dedans) est en fait du code MIPS (petit-boutiste). 


Par exemple, ceci est une fonction épilogue MIPS trés typique: 


ROM: 000013B0 move $sp, $fp 
ROM: 000013B4 lw $ra, Ox1C($sp) 
ROM: 000013B8 lw $fp, 0x18($sp) 


ROM: 000013BC lw $s1, 0x14($sp) 


1235 


ROM: 000013C0 lw $s0, 0x10($sp) 
ROM: 000013C4 jr $ra 
ROM: 000013C8 addiu  $sp, 0x20 


D'aprés notre graphe nous pouvons voir que le code MIPs a une entropie de 5-6 bits 
par octet. En effet, j'ai mesuré une fois l'entropie de différents ISAs et j'ai obtenu 
ces valeurs: 


* x86: section .text du fichier ntoskrnl.exe de Windows 2003: 6.6 

* X64: section .text du fichier ntoskrnl.exe de Windows 7 x64: 6.5 

* ARM (mode thumb), Angry Birds Classic: 7.05 

* ARM (mode ARM) Linux Kernel 3.8.0: 6.03 

* MIPS (little endian), section .text du fichier user32.dll de Windows NT 4: 6.09 


Donc l'entropie du code exécutable est plus grande que du texte en anglais, mais 
peut encore étre compressé. 


Maintenant le second tiers qui commence en OxF5000. Je ne sais pas ce que c'est. 
J'ai essayé différents ISAs mais sans succés. L'entropie de ce bloc semble encore 
plus réguliére que celui de l'exécutable. Peut-étre des sortes de données? 


Il y a aussi un pic en « 02213000. Je l'ai vérifié dans un éditeur hexadécimal et j'y ai 
trouvé un fichier JPEG (qui est, bien sür, compressé)! Je ne sais pas ce qu'il y a à la 
fin. Essayons Binwalk pour ce fichier: 


% binwalk FW96650A.bin 


DECIMAL HEXADECIMAL DESCRIPTION 
y 

167698 0x28F12 Unix path: /15/20/24/25/30/60/120/240fps can 2 
\ be served.. 

280286 0x446DE Copyright string: "Copyright (c) 2012 Novatek 
y Microelectronic Corp." 

2169199 0x21196F JPEG image data, JFIF standard 1.01 

2300847 0x231BAF MySQL MISAM compressed data file Version 3 


% binwalk -E FW96650A.bin 


DECIMAL HEXADECIMAL ENTROPY 
i" 

0 0x0 Falling entropy edge (0.579792) 
2170880 0x212000 Rising entropy edge (0.967373) 
2267136 0x229800 Falling entropy edge (0.802974) 
2426880 0x250800 Falling entropy edge (0.846639) 
2490368 0x260000 Falling entropy edge (0.849804) 
2560000 0x271000 Rising entropy edge (0.974340) 
2574336 0x274800 Rising entropy edge (0.970958) 
2588672 0x278000 Falling entropy edge (0.763507) 
2592768 0x279000 Rising entropy edge (0.951883) 


2596864 0x27A000 Falling entropy edge (0.712814) 
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2600960 0x27B000 Rising entropy edge (0.968167) 
2607104 0x27C800 Rising entropy edge (0.958582) 
2609152 0x27D000 Falling entropy edge (0.760989) 
2654208 0x288000 Rising entropy edge (0.954127) 
2670592 0x28C000 Rising entropy edge (0.967883) 
2676736 0x28D800 Rising entropy edge (0.975779) 
2684928 0x28F800 Falling entropy edge (0.744369) 


Oui, il trouve un fichier JPEG et méme des données MySQL! Mais je ne suis pas certain 
que ca soit vrai—je ne l'ai pas encore vérifié. 


Il est aussi intéressant d'essayer la clusterisation dans Mathematica: 


Infó4]= (+ le s ake a 5 cluster 
ListPlot[FindClusters[entropies]] 


c, "0 e 
‘ 
t A 
. 
x - 
. 
t 
AL 
b . 
7.0} 
$ . 
. 
. LJ 
. . 
e.s} . ete . Poa w o °° D à €. ” 
^S POLL Sn Ne ef tte 78 wert DM ee ft T, e. 
Out[64]- A AR II E SAR E RA am 
Tad . Pia! AS. + e V. os e, LS oe e. K4 q” - 
. 
^ ^ o 
i ste ose . 
"Te e... 2° SX 
EART e emo . 0,0 6. aat 83 
lee E p O g ° 
ERE etc? 
pen Ste Le e... % 
tre 5939 15. 
sh, 1 e + P 
"RON Le.” © 
e. 
oe .. 
Ve SM. 
` 


Ceci est un exemple de la façon dont Mathematica groupe des valeurs d'entropie 
diverses dans des groupes distincts. En effet, c'est quelque chose de plausible. Les 
points bleus dans l'intervalle 5.0-5.5 sont probablement relatif à du texte en anglais, 
Les points jaunes dans 5.5-6 sont du code MIPS. Beaucoup de points verts dans 6.0- 
6.5 sont dans le second tiers non identifié. Les points orange proches de 8.0 sont 
relatifs au fichier JPEG compressé. D'autres points orange sont probablement relatif 
à la fin du firmware (données inconnues pour nous). 


Liens 


Fichiers binaires utilisés dans cette partie: 
https://beginners.re/paywall/RE4B-source/current-tree//ff/entropy/files/. 
Fichier notebook Wolfram Mathematica: 
https://beginners.re/paywall/RE4B-source/current-tree//ff/entropy/files/ 
binary_file entropy.nb 

(toutes les cellules doivent étre évaluées pour que ca commence á fonctionner). 
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9.2.2 Conclusion 


L'entropie peut-étre utilisée comme un moyen rapide d'investigation de fichiers in- 
connus. En particulier, c'est un moyen rapide de trouver des morceaux de données 
compressées/chiffrées. Quelqu'un a dit qu'il est possible de trouver des clefs RSA? 
privées/publiques (et d'autres algorithmes cryptographiques) dans du code exécu- 
table (les clefs ont aussi une trés grande entropie), mais je n'ai pas essayé moi- 
méme. 


9.2.3 Outils 


L'utilitaire Linux ent est trés pratique pour trouver l'entropie d'un fichier$. 


Il y a un excellent visualiseur d'entropie en ligne fait par Aldo Cortesi, que j'ai essayé 
d'imiter avec Mathematica: http://binvis.io. Ses articles sur l'entropie valent la 
peine d'étre lus: http://corte.si/posts/visualisation/entropy/index.html, http: 
//corte.si/posts/visualisation/malware/index.html, http://corte.si/posts/ 
visualisation/binvis/index.html. 


Le quadriciel radare2 a la commande £entropy pour ceci. 
Un outil pour IDA: IDAtropy/. 


9.2.4 Un mot à propos des primitives de chiffrement comme 
le XORage 


Il est intéressant de noter que le chiffrement par un simple XOR n'affecte pas l'en- 
tropie des données. J'ai montré ceci dans l'exemple Norton Guide de ce livre (9.1.2 
on page 1201). 


Généralisation: le chiffrement par substitution n'affecte pas l'entropie des données 
(et XOR peut étre vu comme un chiffrement par substitution). La raison est que 
l'algorithme de calcul de l'entropie voit les données au niveau de l'octet. D'un autre 
cóté, les données chiffrées par un pattern XOR de 2 ou 4 octets donnent un autre 
niveau d'entropie. 


Néanmoins, une entropie basse est en général un signe de chiffrement amateur 
faible (qui est aussi utilisé dans les clefs/fichiers de licence, etc.). 


9.2.5 Plus sur l'entropie de code exécutable 


Il est rapidement perceptible que la plus grande source d'entropie dans du code exé- 
cutable est probablement düe aux offsets encodés dans les opcodes. Par exemple, 
ces deux instructions consécutives vont avoir des offsets relatifs différents dans leur 
opcode, alors qu'elles pointent en fait sur la méme fonction: 


function proc 


5Rivest Shamir Adleman 
Shttp://www. fourmilab.ch/random/ 
7https://github.com/danigargu/IDAtropy 
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function endp 


CALL function 


CALL function 


Un compresseur de code exécutable idéal encoderait l'information comme ceci: // y 
a un CALL à “function” à l'adresse X et la méme CALL à l'adresse Y sans nécessiter 
d'encoder deux fois l'adresse de function. 


Pour gérer ceci, les compresseurs de code exécutable sont parfois capable de ré- 
duire l'entropie ici. Un exemple est UPX: http://sourceforge.net/p/upx/code/ 
ci/default/tree/doc/filter.txt. 


9.2.6 PRNG 


Lorsque je lance GnuPG pour générer une nouvelle clef privée (secréte), il demande 
de l'entropie ... 


We need to generate a lot of random bytes. It is a good idea to perform 
some other action (type on the keyboard, move the mouse, utilize the 
disks) during the prime generation; this gives the random number 
generator a better chance to gain enough entropy. 


Not enough random bytes available. Please do some other work to give 
the OS a chance to collect more entropy! (Need 169 more bytes) 


Ceci signifie qu'un bon PRNG prend longtemps pour produire des résultats avec une 
haute entropie, et ceci est ce dont la clef cryptographique secréte à besoin. Mais 
un CPRNG? est compliqué (car un ordinateur est lui-méme un dispositif hautement 
déterministe), donc GnuPG demande du hasard supplémentaire à l'utilisateur. 


9.2.7 Plus d'exemples 

Voici un cas oü j'ai essayé de calculer l'entropie de certains blocs avec du contenu 
inconnu: 8.9 on page 1112. 

9.2.8 Entropie de fichiers variés 


L'entropie de données aléatoires est proche de 8: 


% dd bs=1M count=1 if-/dev/urandom | ent 
Entropy = 7.999803 bits per byte. 


Ceci signifie que presque tout l'espace disponible d'un octet est rempli d'information. 


256 octets répartis dans l'intervalle 0..255 donnent exactement une valeur de 8: 


8Cryptographically secure PseudoRandom Number Generator 


1239 


#!/usr/bin/env python 
import sys 


for i in range(256): 
sys.stdout.write(chr(i)) 


% python 1.py | ent 
Entropy - 8.000000 bits per byte. 


L'ordre des octets est sans importance. Ceci signifie que tout l'espace dans un octet 
est rempli. 


L'entropie de tout bloc rempli d'octets à zéro est 0: 


% dd bs=1M count=1 if=/dev/zero | ent 
Entropy = 0.000000 bits per byte. 


L'entropie d'une chaîne constituée d'un seul (n'importe lequel) octet est 0: 


*; echo -n "aaaaaaaaaaaaaaaaaaa" | ent 
Entropy - 0.000000 bits per byte. 


L'entropie d'une chaine en base64 est la méme que la données source, mais multi- 
plié par 2. Ceci car l'encodage base64 utilise 64 symboles au lieu de 256. 


% dd bs=1M count=1 if-/dev/urandom | base64 | ent 
Entropy = 6.022068 bits per byte. 


Peut-étre que 6.02, assez proche de 6, est dú au caractére de remplissage (=) qui 
fausse un peu nos statistiques. 


Uuencode utilise aussi 64 symboles: 


% dd bs=1M count=1 if=/dev/urandom | uuencode - | ent 
Entropy = 6.013162 bits per byte. 


Ceci signifie que les chaines base64 et Uuencode peuvent étre transmises en utili- 
sant des octets ou caractéres sur 6-bit. 


Toute information aléatoire au format hexadécimal a une entropie de 4 bits par octet: 


% openssl rand -hex $\$$(( 2**16 )) | ent 
Entropy = 4.000013 bits per byte. 


L'entropie d'un texte en anglais pris au hasard dans la bibliothéque Gutenbert a une 
entropie de ~ 4.5. La raison de ceci est que les textes anglais utilisent principalement 
26 symboles, et log2(26) == 4.7, i.e., vous aurez besoin d'octets de 5-bit pour trans- 
mettre des textes en anglais non compressés, ca sera suffisant (ca l'était en effet 
au temps du télétype). 


Le texte choisi au hasard dans la bibliothèque http: //lib. ru est l’“Idiot”?, de F.M.Dostoevsky 


qui est encodé en CP1251. 


9http://az.lib.ru/d/dostoewskij f m/text 0070.shtml 
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Et ce fichier a une entropie de « 4.98. Le russe comporte 33 caractères et log2(33) —« 
5.04. Mais il le caractère “ë” est impopulaire et rare. Et log2(32) = 5 (l'alphabet russe 
sans ce caractére rare)—maintenant ceci est proche de ce que nous avons obtenu. 


Quoiqu'il en soit, le texte dont nous parlons utilise la lettre “é’, mais, sans doute y 
est-elle rarement utilisée. 


Le méme fichier transcodé de CP1251 en UTF-8 donne une entropie de « 4.23. Chaque 
caractére cyrillique encodé en UTF-8 est généralement encodé en une paire, et le 
premier octet est toujours: OxDO ou OxD1. C'est peut-être ce qui cause ce biais. 


Générons des bits aléatoirement et écrivons les avec les caractéres "T" et "F": 


#!/usr/bin/env python 
import random, sys 


prete 
for i in range(102400): 
if random.randint(0,1)==1: 
rt=rt+"T" 
else: 
rt=rt+"F" 
print rt 


Échantillon: . .. TTTFTFTTTFFFTTTFTTTTTTFTTFFTTTFTFTTFTTFFFFFF. ... 
L'entropie est trés proche de 1 (i.e., 1 bit par octet). 


Générons des chiffres décimaux aléatoirement: 


#!/usr/bin/env python 
import random, sys 


rt=" LL 
for i in range(102400): 

rt=rt+"%d" % random.randint(0,9) 
print rt 


Échantillon: ...52203466119390328807552582367031963888032.... 


L'entropie sera proche de 3.32, en effet, c'est log2(10). 


9.2.9 Réduire le niveau d'entropie 


J'ai vu une fois un logiciel qui stockait chaque octet de données chiffrées sur 3 octets: 


: byt ; n ; ; i 
chacun avait une valeur de Y - donc reconstruire l'octet chiffré impliquait de faire 


la somme de 3 octets consécutifs. Ca semble absurde. 
Mais certaines personnes disent que ca a été fait pour pour cacher le fait que les 


données contenaient quelque chose de chiffré: la mesure de l'entropie d'un tel bloc 
donnait une valeur bien plus faible. 
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9.3 Fichier de sauvegarde du jeu Millenium 


«Millenium Return to Earth » est un ancien jeu DOS (1991), qui vous permet d'extraire 
des ressources, de construire des vaisseaux, de les équiper et de les envoyer sur 
d'autres planétes, et ainsi de suite!®. 


Comme beaucoup d'autres jeux, il vous permet de sauvegarder l'état du jeu dans 
un fichier. 


Regardons si l'on peut y trouver quelque chose. 


101| peut être téléchargé librement ici 
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Donc, il y a des mines dans le jeu. Sur certaines planétes, les mines rapportent plus 
vite, sur d'autres, moins vite. L'ensemble des ressources est aussi différent. 


Ici, nous pouvons voir quelles ressources sont actuellement extraites. 


DOSBox 0.74, Cpu speed: 3000 cycles, Frameskip 0, Program: 2200AD 


H35poGcEn 
[]- 2245; En 
liia TER 
Mi TROGEN 
Me THANE 
SULARHUR 
TiTani um 
ALUMINIUM 
CORRER 
Sicicon 
| ROM 
Silver 
area 
LATINUM 
MAA Dean um 


Fig. 9.14: Mine: état 1 


Sauvegardons l'état du jeu. C'est un fichier de 9538 octets. 


Attendons quelques «jours» dans le jeu, et maintenant, nous avons plus de res- 
sources extraites des mines. 


DOSBox 0.74, Cpu speed: = cycles, Frameskip 0, Program: 2200AD m 


HaunmnmnmEern 
[]-224 5; En 
liia TER 
Ni TROGEN 
METHANE 
SuULAWUR 
Titanium 
[dL.Limi mri Lim 
Conner 
Sicticon 
| Pann 
L| LER 
Curomi um 
PLATINUM 
marie LRAN i.m 


Fig. 9.15: Mine: état 2 


Sauvegardons à nouveau l'état du jeu. 


Maintenant, essayons juste de comparer au niveau binaire les fichiers de sauvegarde 
en utilisant le simple utilitaire DOS/Windows FC: 


..> FC /b 2200save.i.v1 2200SAVE.I.V2 


Comparing files 2200save.i.vl and 2200SAVE.I.V2 
00000016: 0D 04 
00000017: 03 04 
0000001C: 1F 1E 
00000146: 27 3B 
00000BDA: OE 16 
00000BDC: 66 9B 
00000BDE: OE 16 
00000BE0: OE 16 
00000BE6: DB 4C 
00000BE7: 00 01 
00000BE8: 99 E8 
00000BEC: A1 F3 
00000BEE: 83 C7 
00000BFB: A8 28 
00000BFD: 98 18 
00000BFF: A8 28 
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00000C01: A8 28 
00000C07: D8 58 
00000C09: E4 A4 
00000COD: 38 B8 
00000COF: E8 68 


La sortie est incompléte ici, il y a plus de différences, mais j'ai tronqué le résultat 
pour montrer ce qu'il y a de plus intéressant. 


Dans le premier état, nous avons 14 «unités » d'hydrogéne et 102 «unités » d'oxy- 
géne. 

Nous avons respectivement 22 et 155 «unités » dans le second état. Si ces valeurs 
sont sauvées dans le fichier de sauvegarde, nous devrions les voir dans la différence. 
Et en effet, nous les voyons. Il y a OxOE (14) à la position OxBDA et cette valeur est 
à 0x16 (22) dans la nouvelle version du fichier. Ceci est probablement l'hydrogéne. 
Il y a 0x66 (102) à la position OxBDC dans la vieille version et x9B (155) dans la 
nouvelle version du fichier. Il semble que ca soit l'oxygéne. 


Les deux fichiers sont disponibles sur le site web pour ceux qui veulent les inspecter 
(ou expérimenter) plus: beginners.re. 
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Voici la nouvelle version du fichier ouverte dans Hiew, j'ai marqué les valeurs rela- 
tives aux ressources extraites dans le jeu: 


Hiew: 2200save.i.v2 


BERD peo 


Fig. 9.16: Hiew: état 1 


Vérifions chacune d'elles. 


Ce sont clairement des valeurs 16-bits: ce n'est pas étonnant pour un logiciel DOS 
16-bit oü le type int fait 16-bit. 
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Vérifions nos hypothèses. Nous allons écrire la valeur 1234 (0x4D2) a la première 
position (ceci doit être l'hydrogène) : 


C:\tmp\2288save.i.v2 BIFWO EDITMODE 


Fig. 9.17: Hiew: écrivons 1234 (0x4D2) ici 


Puis nous chargeons le fichier modifié dans le jeu et jettons un coup d'oeil aux sta- 
tistiques des mines: 


DOSBox 0.74, Cpu speed: 3000 cycles, Frameskip 0, Program: 2200AD E [cl xj 
A : 


H35poGcEn 
[]-224 5; En 
liia TER 

[li TROGEN 
Me THANE 
SuUuLAHuA 


Titanium 
ALUMINIUM 


PLATINUM 
numm s Limmn i Lim 


Fig. 9.18: Vérifions la valeur pour l'hydrogéne 


Donc oui, c'est bien ca. 
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Maintenant essayons de finir le jeu le plus vite possible, mettons les valeurs maxi- 
males partout: 


C:\DOS\millenium\220@save.i 


Fig. 9.19: Hiew: mettons les valeurs maximales 


OxFFFF représente 65535, donc oui, nous avons maintenant beaucoup de ressources: 


DOSBox 0.74, Cpu speed: 


H345poGcEn 
[]- 2245; En 


Curomi um 
=~ ALATINOUM 
Tr LeRNI um 


Fig. 9.20: Toutes les ressources sont en effet à 65535 (OxFFFF) 
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Laissons passer quelques «jours » dans le jeu et oups! Nous avons un niveau plus 
bas pour quelques ressources: 


DOSBox 0.74, Cpu speed: 3000 cycles, Frameskip 0, Program: 2200AD 


H35poGEn 
[]-2:2 5G; En 
liia TER 
Ni TROGEN 
METHANE 
SULRPHUR 
Titanium 
Heumi mi um 
Conner 
Sicticon 
| mann 
DILYER 
Curomi um 
PLATINUM 
mmm dean um 


Fig. 9.21: Dépassement des variables de ressource 


C'est juste un dépassement. 


Le développeur du jeu n'a probablement pas pensé à un niveau aussi élevé de res- 
sources, donc il n'a pas dû mettre des tests de dépassement, mais les mines «tra- 
vaillent» dans le jeu, des ressources sont extraites, c'est pourquoi il y a des dépas- 
sements. Apparemment, c'est une mauvaise idée d'étre aussi avide. 


Il y a sans doute beaucoup plus de valeurs sauvées dans ce fichier. 


Ceci est donc une méthode trés simple de tricher dans les jeux. Les fichiers des 
meilleurs scores peuvent souvent étre modifiés comme ceci. 


Plus d'informations sur la comparaison des fichiers et des snapshots de mémoire: 
5.10.2 on page 942. 


9.4 fortune programme d'indexation de fichier 


(Cette partie est tout d'abord apparue sur mon blog le 25 avril 2015.) 
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fortune est un programme UNIX bien connu qui affiche une phrase aléatoire depuis 
une collection. Certains geeks ont souvent configuré leur systéme de telle maniére 
que fortune puisse étre appelé aprés la connexion. fortune prend les phrases depuis 
des fichiers texte se trouvant dans /usr/share/games/fortunes (sur Ubuntu Linux). 
Voici un exemple (fichier texte «fortunes ») : 


day for firm decisions!!!!! Or is it? 
few hours grace before the madness begins again. 


gift of a flower will soon be made to you. 


2900200220092 


long-forgotten loved one will appear soon. 


Buy the negatives at any price. 


9 
"6 


A tall, dark stranger will have more fun than you. 


9 
"6 


Donc, il s'agit juste de phrases, parfois sur plusieurs lignes, séparées par le signe 
pourcent. La táche du programme fortune est de trouver une phrase aléatoire et de 
l'afficher. Afin de réaliser ceci, il doit scanner le fichier texte complet, compter les 
phrases, en choisir une aléatoirement et l'afficher. Mais le fichier texte peut étre trés 
gros, et méme sur les ordinateurs modernes, cet algorithme naif est du gaspillage 
de ressource. La facon simple de procéder est de garder un fichier index binaire 
contenant l'offset de chaque phrase du fichier texte. Avec le fichier index, le pro- 
gramme fortune peut fonctionner beaucoup plus vite: il suffit de choisir un index 
aléatoirement, prendre son offset, se déplacer à cet offset dans le fichier texte et 
d'y lire la phrase. C'est ce qui est effectivement fait dans le programme fortune. 
Examinons ce qu'il y a dans ce fichier index (ce sont les fichiers .dat dans le méme 
répertoire) dans un éditeur hexadécimal. Ce programme est open-source bien súr, 
mais intentionnellement, je ne vais pas jeter un coup d'oeil dans le code source. 


% od -t x1 --address-radix=x fortunes.dat 

000000 00 00 00 02 00 00 O1 af 00 00 00 bb 00 00 00 Of 
000010 00 00 00 00 25 00 00 00 OO 00 OO 00 00 OO 00 2b 
000020 00 00 00 60 00 00 00 8f 00 00 00 df 00 00 01 14 
000030 00 00 01 48 00 00 O1 7c 00 00 01 ab 00 00 01 e6 
000040 00 00 02 20 00 00 02 3b 00 00 02 7a 00 00 02 c5 
000050 00 00 03 04 00 00 03 3d 00 00 03 68 00 00 03 a7 
000060 00 00 03 el 00 00 04 19 00 00 04 2d 00 00 04 7f 
000070 00 00 04 ad 00 00 04 d5 00 00 05 05 00 00 05 3b 
000080 00 00 05 64 00 00 05 82 00 00 05 ad 00 00 05 ce 
000090 00 00 05 f7 00 00 06 1c 00 00 06 61 00 00 06 7a 
0000a0 00 00 06 d1 00 00 07 Oa 00 00 07 53 00 00 07 9a 
0000b0 00 00 07 f8 00 00 08 27 00 00 08 59 00 00 08 8b 
0000c0 00 00 08 aO 00 00 08 c4 00 00 08 el 00 00 08 f9 
0000d0 00 00 09 27 00 00 09 43 00 00 09 79 00 00 09 a3 
0000e0 00 00 09 e3 00 00 Oa 15 00 00 Oa 4d 00 00 Oa 5e 
0000f0 00 00 Oa 8a 00 00 Oa a6 00 00 Oa bf 00 00 Oa ef 
000100 00 00 Ob 18 00 00 Ob 43 00 00 Ob 61 00 00 Ob 8e 
000110 00 00 Ob cf 00 00 Ob fa 00 00 Oc 3b 00 00 Oc 66 
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000120 00 00 Oc 85 00 00 Oc b9 00 00 Oc d2 00 00 Od 02 
000130 00 00 Od 3b 00 00 Od 67 00 00 Od ac 00 00 Od eO 
000140 00 00 0e le 00 00 0e 67 00 00 Oe a5 00 00 Oe da 
000150 00 00 0e ff 00 00 Of 43 00 00 Of 8a 00 00 Of bc 
000160 00 00 Of e5 00 00 10 le 00 00 10 63 00 00 10 9d 
000170 00 00 10 e3 00 00 11 10 00 00 11 46 00 00 11 6c 
000180 00 00 11 99 00 00 11 cb 00 00 11 f5 00 00 12 32 
000190 00 00 12 61 00 00 12 8c 00 00 12 ca 00 00 13 87 
0001a0 00 00 13 c4 00 00 13 fc 00 00 14 1a 00 00 14 6f 
0001b0 00 00 14 ae 00 00 14 de 00 00 15 1b 00 00 15 55 
0001cO 00 00 15 a6 00 00 15 d8 00 00 16 Of 00 00 16 4e 


Sans aide particuliére, nous pouvons voir qu'il y a quatre éléments de 4 octets sur 
chaque ligne de 16 octets. Peut-étre que c'est notre tableau d'index. J'essaye de 
charger tout le fichier comme un tableau d'entier 32-bit dans Wolfram Mathematica: 


In[]:= BinaryReadList["c:/tmp1/fortunes.dat", "UnsignedInteger32"] 


Out[]= (33554432, 2936078336, 3137339392, 251658240, 0, 37, 0, \ 
721420288, 1610612736, 2399141888, 3741319168, 335609856, 1208025088, \ 
2080440320, 2868969472, 3858825216, 537001984, 989986816, 2046951424, N 
3305242624, 67305472, 1023606784, 1745027072, 2801991680, 3775070208, \ 
419692544, 755236864, 2130968576, 2902720512, 3573809152, 84213760, \ 
990183424, 1678049280, 2181365760, 2902786048, 3456434176, \ 
4144300032, 470155264, 1627783168, 2047213568, 3506831360, 168230912, \ 
1392967680, 2584150016, 4161208320, 654835712, 1493696512, \ 
2332557312, 2684878848, 3288858624, 3775397888, 4178051072, \ 


Nope, quelque chose est faux, les nombres sont étrangement gros. Mais retournons 
a la sortie de od : chaque élément de 4 octets a deux octets nuls et deux octets non 
nuls. Donc les offsets (au moins au début du fichier) sont au maximum 16-bit. Peut- 
étre qu’un endianness différent est utilisé dans le fichier? L’endianness par défaut 
dans Mathematica est little-endian, comme utilisé dans les CPUs Intel. Maintenant, 
je le change en big-endian: 


In[]:= BinaryReadList["c:/tmp1/fortunes.dat", "UnsignedInteger32", 
ByteOrdering -> 1] 


Out[]= (2, 431, 187, 15, 0, 620756992, 0, 43, 96, 143, 223, 276, N 
328, 380, 427, 486, 544, 571, 634, 709, 772, 829, 872, 935, 993, \ 
1049, 1069, 1151, 1197, 1237, 1285, 1339, 1380, 1410, 1453, 1486, 
1527, 1564, 1633, 1658, 1745, 1802, 1875, 1946, 2040, 2087, 2137, 
2187, 2208, 2244, 2273, 2297, 2343, 2371, 2425, 2467, 2531, 2581, 
2637, 2654, 2698, 2726, 2751, 2799, 2840, 2883, 2913, 2958, 3023, 
3066, 3131, 3174, 3205, 3257, 3282, 3330, 3387, 3431, 3500, 3552, 


PO PO GE GO um 


Qui, c'est quelque chose de lisible. Je choisi un élément au hasard (3066) qui s'écrit 
OxBFA en format hexadécimal. J'ouvre le fichier texte 'fortunes' dans un éditeur hexa- 
décimal, je met l'offset OxBFA et je vois cette phrase: 
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% od -t x1 -c --skip-bytes=0xbfa --address-radix=x fortunes 
000bfa 44 6f 20 77 68 61 74 20 63 6f 6d 65 73 20 6e 61 
D (0) w h a t C (0) m e S 
000c0a 74 75 72 61 6c 6c 79 2e 20 20 53 65 65 74 68 65 
t u r a l l y . S e e t h e 
000cla 20 61 6e 64 20 66 75 6d 65 20 61 6e 64 20 74 68 
a n d f u m e a n d t h 


Ou: 


Do what comes naturally. Seethe and fume and throw a tantrum. 


% 


D’autres offsets peuvent aussi étre essayés, oui, ils sont valides. 


Je peux aussi vérifier dans Mathematica que chaque élément consécutif est plus 
grand que le précédent. l.e., les éléments du tableau sont croissants. Dans le jargon 


mathématiques, ceci est appelé fonction monotone strictement croissante. 


In[]:= Differences[input] 


Out[]= (429, -244, -172, -15, 620756992, -620756992, 43, 53, 47, N 

80, 53, 52, 52, 47, 59, 58, 27, 63, 75, 63, 57, 43, 63, 58, 56, 20, \ 
82, 46, 40, 48, 54, 41, 30, 43, 33, 41, 37, 69, 25, 87, 57, 73, 71, \ 
94, 47, 50, 50, 21, 36, 29, 24, 46, 28, 54, 42, 64, 50, 56, 17, 44, \ 
28, 25, 48, 41, 43, 30, 45, 65, 43, 65, 43, 31, 52, 25, 48, 57, 44, \ 
69, 52, 62, 73, 62, 53, 37, 68, 71, 50, 41, 57, 69, 58, 70, 45, 54, \ 
38, 45, 50, 42, 61, 47, 43, 62, 189, 61, 56, 30, 85, 63, 48, 61, 58, \ 
81, 50, 55, 63, 83, 80, 49, 42, 94, 54, 67, 81, 52, 57, 68, 43, 28, \ 


120, 64, 53, 81, 33, 82, 88, 29, 61, 32, 75, 63, 70, 47, 101, 60, 79, \ 


33, 48, 65, 35, 59, 47, 55, 22, 43, 35, 102, 53, 80, 65, 45, 31, 29, \ 
69, 32, 25, 38, 34, 35, 49, 59, 39, 41, 18, 43, 41, 83, 37, 31, 34, \ 
59, 72, 72, 81, 77, 53, 53, 50, 51, 45, 53, 39, 70, 54, 103, 33, 70, \ 
51, 95, 67, 54, 55, 65, 61, 54, 54, 53, 45, 100, 63, 48, 65, 71, 23, \ 
28, 43, 51, 61, 101, 65, 39, 78, 66, 43, 36, 56, 40, 67, 92, 65, 61, \ 
31, 45, 52, 94, 82, 82, 91, 46, 76, 55, 19, 58, 68, 41, 75, 30, 67, \ 


92, 54, 52, 108, 60, 56, 76, 41, 79, 54, 65, 74, 112, 76, 47, 53, 61, \ 


66, 53, 28, 41, 81, 75, 69, 89, 63, 60, 18, 18, 50, 79, 92, 37, 63, \ 
88, 52, 81, 60, 80, 26, 46, 80, 64, 78, 70, 75, 46, 91, 22, 63, 46, \ 
34, 81, 75, 59, 62, 66, 74, 76, 111, 55, 73, 40, 61, 55, 38, 56, 47, \ 
78, 81, 62, 37, 41, 60, 68, 40, 33, 54, 34, 41, 36, 49, 44, 68, 51, \ 
50, 52, 36, 53, 66, 46, 41, 45, 51, 44, 44, 33, 72, 40, 71, 57, 55, \ 
39, 66, 40, 56, 68, 43, 88, 78, 30, 54, 64, 36, 55, 35, 88, 45, 56, \ 
76, 61, 66, 29, 76, 53, 96, 36, 46, 54, 28, 51, 82, 53, 60, 77, 21, \ 
84, 53, 43, 104, 85, 50, 47, 39, 66, 78, 81, 94, 70, 49, 67, 61, 37, \ 
51, 91, 99, 58, 51, 49, 46, 68, 72, 40, 56, 63, 65, 41, 62, 47, 41, \ 
43, 30, 43, 67, 78, 80, 101, 61, 73, 70, 41, 82, 69, 45, 65, 38, 41, \ 
57, 82, 66} 


Comme on le voit, excepté les 6 premiéres valeurs (qui appartiennent sans doute 
a l'entéte du fichier d’index), tous les nombres sont en fait la longueur des phrases 
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de texte (l'offset de la phrase suivante moins l'offset de la phrase courante est la 
longueur de la phrase courante). 


Il est trés important de garder à l'esprit que l'endianness peut être confondu avec un 
début de tableau incorrect. En effet, dans la sortie d'od nous voyons que chaque élé- 
ment débutait par deux zéros. Mais lorsque nous décalons les des octets de chaque 
CÓté, nous pouvons interpréter ce tableau comme little-endian: 


% od -t x1 --address-radix=x --skip-bytes=0x32 fortunes.dat 
000032 01 48 00 00 01 7c 00 00 01 ab 00 00 01 e6 00 00 
000042 02 20 00 00 02 3b 00 00 02 7a 00 00 02 c5 00 00 
000052 03 04 00 00 03 3d 00 00 03 68 00 00 03 a7 00 00 
000062 03 el 00 00 04 19 00 00 04 2d 00 00 04 7f 00 00 
000072 04 ad 00 00 04 d5 00 00 05 05 00 00 05 3b 00 00 
000082 05 64 00 00 05 82 00 00 05 ad 00 00 05 ce 00 00 
000092 05 f7 00 00 06 1c 00 00 06 61 00 00 06 7a 00 00 
000022 06 d1 00 00 07 Oa 00 00 07 53 00 00 07 Ya 00 00 
0000b2 07 f8 00 00 08 27 00 00 08 59 00 00 08 8b 00 00 
0000c2 08 a0 00 00 08 c4 00 00 08 el 00 00 08 f9 00 00 
0000d2 09 27 00 00 09 43 00 00 09 79 00 00 09 a3 00 00 
0000e2 09 e3 00 00 Oa 15 00 00 Oa 4d 00 00 Oa 5e 00 00 


Si nous interprétons ce tableau en little-endian, le premier élément est 0x4801, le 
second est 0x7CO1, etc. La partie 8-bit haute de chacune de ces valeurs 16-bit nous 
semble étre aléatoire, et la partie 8-bit basse semble étre ascendante. 


Mais je suis sür que c'est un tableau en big-endian, car le tout dernier élément 32-bit 
du fichier est big-endian. (00 00 5f c4 ici) : 


% od -t x1 --address-radix=x fortunes.dat 


000660 00 00 59 Od 00 00 59 55 00 00 59 7d 00 00 59 b5 
000670 00 00 59 f4 00 00 5a 35 00 00 5a 5e 00 00 5a 9c 
000680 00 00 5a cb 00 00 5a f4 00 00 5b 1f 00 00 5b 3d 
000690 00 00 5b 68 00 00 5b ab 00 00 5b f9 00 00 5c 49 
0006a0 00 00 5c ae 00 00 5c eb 00 00 5d 34 00 00 5d 7a 
0006b0 00 00 5d a3 00 00 5d f5 00 00 5e 3a 00 00 5e 67 
0006cO 00 00 5e a8 00 00 5e ce 00 00 5e f7 00 00 5f 30 
0006d0 00 00 5f 82 00 00 5f c4 

0006d8 


Peut-étre que le développeur du programme fortune avait un ordinateur big-endian 
ou peut-étre a-t-il été porté depuis quelque chose comme ca. 


Ok, donc le tableau est big-endian, et, á en juger avec bon sens, la toute premiére 
phrase dans le fichier texte doit commencer a l'offset zéro. Donc la valeur zéro doit se 
trouver dans le tableau quelque part au tout début. Nous avons un couple d'élément 
à zéro au début. Mais le second est plus tentant: 43 se trouve juste aprés et 43 est 
un offset valide sur une phrase anglaise correcte dans le fichier texte. 


Le dernier élément du tableau est Ox5FC4, et il n'y a pas de tel octet à cet offset 
dans le fichier texte. Donc le dernier élément du tableau pointe au delà de la fin du 
fichier. C'est probablement ainsi car la longueur de la phrase est calculée comme la 
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différence entre l'offset de la phrase courante et l'offset de la phrase suivante. Ceci 
est plus rapide que de lire la chaine à la recherche du caractére pourcent. Mais ceci 
ne fonctionne pas pour le dernier élément. Donc un élément fictif est aussi ajouté à 
la fin du tableau. 


Donc les 6 premiére valeur entiére 32-bit sont une sorte d'en-téte. 


Oh, j'ai oublié de compter les phrases dans le fichier texte: 


% cat fortunes | grep % | wc -1 
432 


Le nombre de phrases peut étre présent dans dans l'index, mais peut-étre pas. Dans 
le cas de fichiers d'index simples, le nombre d'éléments peut étre facilement déduit 
de la taille du fichier d'index. Quoiqu'il en soit, il y a 432 phrases dans le fichier texte. 
Et nous voyons quelque chose de trés familier dans le second élément (la valeur 
431). J'ai vérifié dans d'autres fichiers (literature.dat et riddles.dat sur Ubuntu Linux) 
et oui, le second élément 32-bit est bien le nombre de phrases moins 1. Pourquoi 
moins 1? Peut-étre que ceci n'est pas le nombre de phrases, mais plutót le numéro 
de la derniére phrase (commengant à zéro)? 


Et il y a d'autres éléments dans l'entéte. Dans Mathematica, je charge chacun des 
trois fichiers disponible et je regarde leur en-téte: 


In14;= input = BinaryReadList["c:/tmpi/fortunes.dat", "UnsignedInteger32", 
ByteOrdering 51]: 


r8; BaseForm[Take[input, (1, 6)], 16] 


Out[18y/BaseForm- 
1216, lafie, bbie, fie, O16, 2500000016) 


n[19):= input = BinaryReadList["c:/tmp1/literature.dat", "UnsignedInteger32", 
ByteOrdering +1]; 


i22; BaseForm[Take[input, (1, 6)], 16] 


Out[20y/BaseForm- 
1216, 10616, 98316, laic, 01e, 2500000016} 


Inf21= input = BinaryReadList["c:/tmp1/riddles.dat", "UnsignedInteger32", ByteOrdering 1]: 


122; BaseForm[Take[input, (1, 6}], 16] 


Out[22V/BaseForm- 


1216, 8016, 7f216, 2416, O16, 2500000016) 


Je n'ai aucune idée de la signification des autres valeurs, excepté la taille du fichier 
d'index. Certains champs sont les méme pour tous les fichiers, d'autres non. D'après 
mon expérience, ils peuvent étre: 


* signature de fichier; 
* version de fichier; 


* checksum; 
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* des flags; 
* peut-étre méme des identifiants de langages; 


* timestamp du fichier texte, donc le programme fortune regénérerait le fichier 
d'index isi l'utilisateur modifiait le fichier texte. 


Par exemple, les fichiers Oracle .SYM (9.5 on the following page) qui contiennent la 
table des symboles pour les fichiers DLL, contiennent aussi un timestamp correspon- 
dant au fichier DLL, afin d'étre súr qu'il est toujours valide. 


D'un autre cóté, les timestamps des fichiers textes et des fichiers d'index peuvent 
étre désynchronisés aprés archivage/désarchivage/installation/déploiement/etc. 


Mais ce ne sont pas des timestamps, d'aprés moi. La maniére la plus compacte de 
représenter la date et l'heure est la valeur UNIX, qui est un nombre 32-bit. Nous ne 
voyons rien de tel ici. D'autres facons de les représenter sont encore moins com- 
pactes. 


Donc, voici supposément comment fonctionne l'algorithme de fortune : 


prendre le nombre du second élément de la derniére phrase; 


générer un nombre aléatoire dans l'intervalle O..number of last phrase; 


trouver l'élément correspondant dans le tableau des offsets, prendre aussi l'off- 
set suivant; 


écrire sur stdout tous les caractéres depuis le fichier texte en commengant à 
l'offset jusqu'à l'offset suivant moins 2 (afin d'ignorer le caractére pourcent 
terminal et le caractére de la phrase suivante). 


9.4.1 Hacking 


Effectuons quelques essais afin de vérifier nos hypothéses. Je vais créer ce fichier 
texte dans le chemin et le nom /usr/share/games/fortunes/fortunes : 


Phrase one. 


9 
"6 


Phrase two. 


9 
"6 


Puis, ce fichier fortunes.dat. Je prend l'entéte du fichier original fortunes.dat, j'ai mis 
à zéro changé le second champ (nombre de phrases) et j'ai laissé deux éléments 
dans le tableau: O et Ox1c, car la longueur totale du fichier texte fortunes est 28 
(Ox1c) octets: 


% od -t x1 --address-radix=x fortunes.dat 
000000 00 00 00 02 00 00 OO 00 OO 00 OO bb 00 00 00 Of 
000010 00 00 00 00 25 00 00 00 OO 00 00 OO 00 00 00 1c 


Maintenant, je le lance: 


% /usr/games/fortune 
fortune: no fortune found 


1255 


Quelque chose ne va pas. Mettons le second champ à 1: 


% od -t x1 --address-radix=x fortunes.dat 
000000 00 00 00 02 00 00 OO 01 OO 00 OO bb 00 00 00 Of 
000010 00 00 00 00 25 00 00 00 OO 00 00 OO 00 00 00 Ic 


Maintenant, ca fonctionne. Il affiche seulement la première phrase: 


% /usr/games/fortune 
Phrase one. 


Hmmm. Laissons seulement un élément dans le tableau (0) sans le terminer: 


% od -t x1 --address-radix=x fortunes.dat 

000000 00 00 00 02 00 OO OO 01 OO 00 OO bb 00 00 00 Of 
000010 00 00 00 00 25 00 00 00 00 00 00 00 

00001c 


Le programme Fortune montre toujours seulement la premiére phrase. 


De cet essai nous apprenons que la signe pourcent dans le fichier texte est analysé 
et la taille n'est pas calculée comme je l'avais déduit avant, peut-étre que méme 
l'élément terminal du tableau n'est pas utilisé. Toutefois, il peut toujours l'étre. Et 
peut-étre qu'il l'a été dans le passé? 


9.4.2 Les fichiers 


Pour les besoins de la démonstration, je ne regarde toujours pas dans le code source 
de fortune. Si vous soulez essayer de comprendre la signification des autres valeurs 
dans l'entéte du fichier d'index, vous pouvez essayer de le faire sans regarder dans 
le code source. Les fichiers que j'ai utilisé sous Ubuntu Linux 14.04 sont ici: http: 
//beginners.re/examples/fortune/, les fichiers bricolés le sont aussi. 


Oh, j'ai pris les fichiers de la version x64 d'Ubuntu, mais les éléments du tableau 
ont toujours une taille de 32 bit. C'est parce que les fichiers de texte de fortune ne 
vont sans doute jamais dépasser une taille de 4GiB!. Mais s'ils le devaient, tous les 
éléments devraient avoir une taille de 64 bit afin de pouvoir stocker un offset de 
dans un fichier texte plus gros que 4GiB. 


Pour les lecteurs impatients, le code source de fortune est ici: https :// launchpad. 
net/ubuntu/-*source/fortune-mod/1:1.99.1-3. 1ubuntu4. 


9.5 Oracle RDBMS : fichiers .SYM 


Lorsqu'un processus d'Oracle RDBMS rencontre un sorte de crash, il écrit beaucoup 
d'information dans les fichiers de trace, incluant la trace de la pile, comme ceci: 


----- Call Stack Trace ----- 
calling call entry argument values in hex 


11Gibibyte 
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location type point (? means dubious value) 
naaa a a A A a ss es P4 
S A ee ee ee ee ee ee eee ee 
_kqvrow() 00000000 
_opifch2()+2729 CALLptr 00000000 23D4B914 E47F264 1F19AE2 
EB1C8A8 1 
_kpoal8() +2832 CALLrel _opifch2() 89 5 EB1CC74 
_opiodr()+1248 CALLreg 00000000 5E 1C EB1FOAO 
_ttcpip()+1051 CALLreg 00000000 5E 1C EB1F0A0 0 
_opitsk()+1404 CALL??? 00000000 C96C040 5E EB1FOAO O 7 
y EB1ED30 
EB1F1CC 53E52E 0 EB1F1F8 
_opiino()+980 CALLrel _opitsk() 00 
_opiodr()+1248 CALLreg 00000000 3C 4 EB1FBF4 
_opidrv()+1201 CALLrel — opiodr() 3C 4 EB1FBF4 0 
_sou20()+55 CALLrel _opidrv() 3C 4 EB1FBF4 
_opimai real()+124 CALLrel sou2o() EB1FCO4 3C 4 EB1FBF4 
_opimai()+125 CALLrel — opimai real() 2 EBIFC2C 
_OracleThreadStart@  CALLrel _opimai() 2 EB1FF6C 7C88A7F4 2 
S EB1FC34 0 
4()+830 EB1FD04 
77E6481C CALLreg 00000000 E41FF9C 0 O E41FF9C O 2 
S EBIFFCA 
00000000 CALL??? 00000000 


Mais bien sür, les exécutables d'Oracle RDBMS doivent avoir une sorte d'information 
de débogage ou de fichiers de carte avec l'information sur les symboles incluse ou 
quelque chose comme ca. 


Oracle RDBMS sur Windows NT a l'information sur les symboles incluse dans des 
fichiers avec l'extension .SYM, mais le format est propriétaire. (Les fichiers texte en 
clair sont bons, mais nécessite une analyse supplémentaire, d'où un accès plus lent.) 


Voyons si nous pouvons comprendre son format. 


Nous allons choisir le plus petit fichier orawtc8. sym qui vient avec le fichier orawtc8.dll 
dans Oracle 8.1.7??. 


12Nous pouvons choisir une version plus ancienne d'Oracle RDBMS intentionnellement à cause de la 
plus petite taille de ses modules. 


Voici le fichier ouvert dans Hiew: 


Fig. 9.22: Le fichier entier dans Hiew 


En comparant le fichier avec d'autres fichiers .SYM, nous voyons rapidement que 
OSYM est toujours en entéte (et en fin de fichier), donc c'est peut-étre la signature 
du fichier. 


Nous voyons que, en gros, le format de fichier est: OSYM + des données binaires 
+ un zéro délimiteur de chaine de texte + OSYM. Les chaines sont évidemment les 
noms des fonctions et des variables globales. 
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Nous allons marquer les signatures OSYM et les chaines ici: 


Hiew: orawtc8.sym d 


Fig. 9.23: Signatures OSYM et chaínes de texte 


Bon, voyons. Dans Hiew, nous allons marquer le bloc de chaines complet (excepté 
les signatures OSYM) et les mettre dans un fichier séparé. Puis, nous lancons les 
utilitaires UNIX strings et wc pour compter les chaínes de texte: 


strings strings block | wc -l 
66 


Donc, il y a 66 chaines de texte. Veuillez noter ce nombre. 


Nous pouvons dire, en général, comme une régle, que le nombre de quelque chose 
est souvent stocké séparément dans des fichiers binaires. 


C'est en effet ainsi, nous pouvons trouver la valeur 66 (0x42) au début du fichier, 
juste aprés la signature OSYM: 


$ hexdump -C orawtc8.sym 
00000000 4f 53 59 4d 42 00 00 00 00 10 00 10 80 10 00 10  |OSYMB? 


| 
00000010 fO 10 00 10 50 11 00 10 60 11 00 10 cO 11 00 10 |....Py 
NI HAC UM | 


00000020 de 11 00 10 70 13 00 10 40 15 00 10 50 15 00 10 |....p...@...P¥ 


e il 
00000030 60 15 00 10 80 15 00 10 a0 15 00 10 a6 15 00 10 2 
CERRO M | 


Bien sûr, 0x42 n'est pas ici un octet, mais plus probablement une velaur 32-bit pa- 
ckée en petit-boutiste, ainsi nous pouvons voir 0x42 et ensuite au moins 3 octets à 
zéro. 


Pourquoi croyons-nous que c'est 32-bit? Car les fichiers de symboles d'Oracle RDBMS 
peuvent être plutôt gros. 


Le fichier oracle.sym pour l'exécutable principal oracle.exe (version 10.2.0.4) contient 
0x3A38E (238478) symboles. 


Nous pouvons vérifier d'autres fichiers .SYM comme ceci et ça prouve notre suppo- 
sition: la valeur après la signature 32-bit OSYM représente toujours le nombre de 
chaînes de texte dans le fichier. 


C'est une caractéristique générale de presque tous les fichiers binaires: un entéte 
avec une signature ainsi que d'autres informations sur le fichier. 


Maintenant, examinons de plus près ce qu'est ce bloc binaire. 


En utilisant Hiew, nous extrayons le bloc débutant à l'offset 8 (i.e., aprés la valeur 
32-bit count) se terminant au bloc de chaînes, dans un fichier binaire séparé. 
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Voyons le bloc binaire dans Hiew: 


00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 
00000060: 
00000070: 
00000080: 
00000090: 
00000040: 
000000B0: 
000000C0: 
000000D0: 
000000E0: 
000000F0: 
00000100: 
00000110: 
00000120: 
00000130: 
00000140: 
00000150: 
00000160: 
00000170: 
00000180: 
00000190: 
000001A0: 


A 
El 
El 
El 
IE 
A 
B| 
El 
Di 
E 


Fig. 9.24: Bloc binaire 


Il y un motif clair dedans. 
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Nous ajoutons des lignes rouges pour diviser le bloc: 


EF] Hiew: asd2 E 


00000000: 10 00 10 
00000010: 11 00 10 
00000020: 15 00 10 
00000030: 15 00 10 
00000040: 15 00 10 
00000050: 15 00 10 
00000060: 17 00 10 
00000070: 17 00 10 
00000080: 20 00 10 
00000090: 20 00 10 
00000040: 20 00 10 
000000B0: 20 00 10 
000000C0: 20 00 10 
000000DO : 20 00 10 
000000E0: 21 00 10 
000000F0 : 30 00 10 
00000100: 30 00 10 
00000110: 00 00 00 
00000120: 00 00 00 
00000130: 00 00 00 
00000140: 00 00 00 
00000150: 00 00 00 
00000160: 00 00 00 
00000170: 01 00 00 
00000180: 01 00 00 
00000190: 01 00 00 
000001A0: FB 01 00 00 
000001B0: 3D 02 00 00 
1Global 2FilBlk 3CryBlk 


090000000 


œ IL O5) ^ [D Y 


© 


Ez) Fg) C) C) C) CX) C) DC) Cy) [y] 


© E) © © © © © CD E 


0 
e 
P 


= 
© 


o E) © © © CS) © DV) D) 


E) © © © © CX) © (x 


jm 


— Time © MN 0 [S 
* [y r-Iuu uz 
FONO: 


Es 
se m 
3 © © © a 


Uy) 


Eu 
E D) © © CD C 
Ww 


= 


Fig. 9.25: Schéma de bloc binaire 


Hiew, comme presque n'importe quel autre éditeur hexadécimal, montre 16 octets 
par ligne. Donc le motif est clairement visible: il y a 4 valeurs 32-bit par ligne. 


Le schéma est visible visuellement car certaines valeurs ici (jusqu’a l'adresse 0x104 
sont toujours de la forme 0x1000xxxx, commencant par 0x10 et des octets a zéro. 


D'autres valeurs (commençant à 0x108) sont de la forme 0x0000xxxx, donc com- 
mencent toujours par deux octets a zéro. 


Affichons le bloc comme un tableau de valeurs 32-bit: 


Listing 9.10 : la premiére colonne est l'adresse 


$ od -v -t x4 binary_block 
0000000 10001000 10001080 100010f0 10001150 
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0000020 10001160 100011c0 100011d0 10001370 
0000040 10001540 10001550 10001560 10001580 
0000060 100015a0 10001526 100015ac 100015b2 
0000100 100015b8 100015be 100015c4 100015ca 
0000120 100015d0 100015e0 100016b0 10001760 
0000140 10001766 1000176c 10001780 100017b0 
0000160 100017d0 100017e0 10001810 10001816 
0000200 10002000 10002004 10002008 1000200c 
0000220 10002010 10002014 10002018 1000201c 
0000240 10002020 10002024 10002028 1000202c 
0000260 10002030 10002034 10002038 1000203c 
0000300 10002040 10002044 10002048 1000204c 
0000320 10002050 100020d0 100020e4 100020f8 
0000340 1000210c 10002120 10003000 10003004 
0000360 10003008 1000300c 10003098 1000309c 
0000400 100030a0 100030a4 00000000 00000008 
0000420 00000012 0000001b 00000025 0000002e 
0000440 00000038 00000040 00000048 00000051 
0000460 0000005a 00000064 0000006e 0000007a 
0000500 00000088 00000096 000000a4 000000ae 
0000520 000000b6 000000cO 000000d2 000000e2 
0000540 000000f0 00000107 00000110 00000116 
0000560 00000121 0000012a 00000132 0000013a 
0000600 00000146 00000153 00000170 00000186 
0000620 000001a9 000001c1 000001de 000001ed 
0000640 000001fb 00000207 0000021b 0000022a 
0000660 0000023d 0000024e 00000269 00000277 
0000700 00000287 00000297 000002b6 000002ca 
0000720 000002dc 000002f0 00000304 00000321 
0000740 0000033e 0000035d 0000037a 00000395 
0000760 000003ae 000003b6 000003be 000003c6 
0001000 000003ce 000003dc 000003e9 000003f8 
0001020 


Il y a 132 valeurs, qui vaut 66*3. Peut-étre qu'il y a deux valeurs 32-bit pour chaque 
symbole, mais peut-étre y a-t-il deux tableaux? Voyons 


Les valeurs débutant par 0x1000 peuvent étre une adresse. 


Ceci est un fichier .SYM pour une DLL aprés tout, et l'adresse de base par défaut des 
DLL win32 est 0x10000000, et le code débute en général en 0x10001000. 


Lorsque nous ouvrons le fichier orawtc8.dll dans IDA, l'adresse de base est différente, 
mais néanmoins, la premiére fonction est: 


.text:60351000 sub 60351000 proc near 
.text:60351000 
.text:60351000 arg 0 
.text:60351000 arg 4 
.text:60351000 arg 8 
.text:60351000 
.text:60351000 push ebp 

.text:60351001 mov ebp, esp 
.text:60351003 mov eax, dword 60353014 


dword ptr 8 
dword ptr OCh 
dword ptr 10h 
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.text:60351008 cmp eax, OFFFFFFFFh 
.text:6035100B jnz short loc 6035104F 
.text:6035100D mov ecx, hModule 
.text:60351013 xor eax, eax 

.text:60351015 cmp ecx, OFFFFFFFFh 
.text:60351018 mov dword 60353014, eax 
.text:6035101D jnz short loc 60351031 
.text:6035101F call sub 603510F0 
.text:60351024 mov ecx, eax 

.text:60351026 mov eax, dword 60353014 
.text:6035102B mov hModule, ecx 
.text:60351031 

.text:60351031 loc 60351031: ; CODE XREF: sub 60351000+1D 
.text:60351031 test ecx, ecx 

.text:60351033 jbe short loc 6035104F 
.text:60351035 push offset ProcName ; "ax reg" 
.text:6035103A push ecx ; hModule 
.text:6035103B call ds:GetProcAddress 


Ouah, la chaine «ax reg » me dit quelque chose. 


C'est en effet la première chaîne dans le bloc de chaîne! Donc le nom de cette 
fonction semble étre «ax reg ». 


La seconde fonction est: 


.text:60351080 sub 60351080 proc near 
.text:60351080 
.text:60351080 arg 0 
.text:60351080 arg 4 
.text:60351080 


dword ptr 8 
dword ptr OCh 


.text:60351080 push ebp 

.text:60351081 mov ebp, esp 

.text:60351083 mov eax, dword 60353018 
.text:60351088 cmp eax, OFFFFFFFFh 
.text:6035108B jnz short loc 603510CF 
.text:6035108D mov ecx, hModule 

.text:60351093 xor eax, eax 

.text:60351095 cmp ecx, OFFFFFFFFh 
.text:60351098 mov dword 60353018, eax 
.text:6035109D jnz short loc 603510B1 
.text:6035109F call sub 603510F0 

.text:603510A4 mov ecx, eax 

.text:603510A6 mov eax, dword 60353018 
.text:603510AB mov hModule, ecx 

.text:603510B1 

.text:603510B1 loc 603510B1: ; CODE XREF: sub 60351080+1D 
.text:603510B1 test ecx, ecx 

.text:603510B3 jbe short loc 603510CF 
.text:603510B5 push offset aAx unreg ; "ax unreg" 
.text:603510BA push ecx ; hModule 


.text:603510BB call ds:GetProcAddress 
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La chaine «ax unreg » est aussi la seconde chaine dans le bloc de chaíne! 


L'adresse de début de la seconde fonction est 0x60351080, et la seconde valeur 
dans le bloc binaire est 10001080. Donc ceci est l'adresse, mais pour une DLL avec 
l'adresse de base par défaut. 


Nous pouvons rapidement vérifier et étre sür que les 66 premiéres valeurs dans 
le tableau (i.e., la premiére moitié du tableau) sont simplement les adresses des 
fonctions dans la DLL, incluant quelques labels, etc. Bien, qu'est-ce que l'autre partie 
du tableau? Les autres 66 valeurs qui commencent par 0x0000 ? Elles semblent étre 
dans l'intervalle [0...0x3F8]. Et elles ne ressemblent pas à des champs de bits: la 
série de nombres augmente. 


Le dernier chiffre hexadécimal semble étre aléatoire, donc, il est peu probable que 
ca soit l'adresse de quelque chose (il serait divisible par 4 ou peut-étre 8 ou 0x10 
autrement). 


Demandons-nous: qu'est-ce que les développeurs d'Oracle RDBMS pourraient avoir 
sauvegardé ici, dans ce fichier? 


Supposition rapide: ca pourrait étre l'adresse de la chaine de texte (nom de la fonc- 
tion). 


Ca peut étre vérifié rapidement, et oui, chaque nombre est simplement la position 
du premier caractère dans le bloc de chaînes. 


Ca y est! C'est fini. 


Nous allons écrire un utilitaire pour convertir ces fichiers .SYM en un script IDA, donc 
nous pourrons charger le script .idc et mettre les noms de fonction: 


#include <stdio.h> 
#include <stdint.h> 
#include <io.h> 
#include <assert.h> 
#include <malloc.h> 
#include <fcntl.h> 
#include <string.h> 


int main (int argc, char *argv[]) 
{ 
uint32 t sig, cnt, offset; 
uint32 t *dl, *d2; 
int h, i, remain, file len; 
char *d3; 
uint32 t array size in bytes; 


assert (argv[1]); // file name 
assert (argv[2]); // additional offset (if needed) 


// additional offset 
assert (sscanf (argv[2], "%X", &offset)==1); 


// get file length 
assert ((h=open (argv[1], _0 RDONLY | 0 BINARY, 0))!--1); 
assert ((file len-lseek (h, 0, SEEK END))!=-1); 
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assert (lseek (h, 0, SEEK SET)!=-1); 


// read signature 

assert (read (h, &sig, 4)==4); 
// read count 

assert (read (h, &cnt, 4)==4); 


assert (sig==0x4D59534F); // OSYM 


// skip timedatestamp (for 11g) 
// \seek (h, 4, 1); 


array size in bytes=cnt*sizeof(uint32 t); 


// load symbol addresses array 

dl-(uint32 t*)malloc (array size in bytes); 

assert (d1); 

assert (read (h, dl, array size in bytes)--array size in bytes); 


// load string offsets array 

d2-(uint32 t*)malloc (array size in bytes); 

assert (d2); 

assert (read (h, d2, array size in bytes)--array size in bytes); 


// calculate strings block size 
remain=file_len- (8+4) -(cnt*8) ; 


// load strings block 
assert (d3=(char*)malloc (remain) ); 
assert (read (h, d3, remain)==remain) ; 


printf ("#include <idc.idc>\n\n"); 
printf ("static main() {\n"); 


for (i=0; i<cnt; i++) 
printf ("NtMakeName(0x9508X, \"%s\");\n", offset + d1l[i], € 2 
y d3[d2[i]]); 


printf ("}\n"); 
close (h); 


free (d1); free (d2); free (d3); 
}; 


Voici un exemple de comment ça fonctionne: 


#include <idc.idc> 


static main() { 
MakeName(0x60351000, " ax reg"); 
MakeName(0x60351080, " ax unreg"); 
MakeName(0x603510F0, " loaddll"); 
MakeName(0x60351150, " wtcsrin0"); 
MakeName(0x60351160, " wtcsrin"); 
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MakeName(0x603511C0, " wtcsrfre"); 
MakeName(0x603511D0, " wtclkm"); 
MakeName(0x60351370, " wtcstu"); 


Les fichiers d'exemple qui ont été utilisés dans cet exemple sont ici: beginners.re. 
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Oh, essayons avec Oracle RDBMS pour win64. Les adresses devraient faire 64-bit, 
n'est-ce pas? 


Le motif sur 8 octets est visible encore plus facilement ici: 


oracle.sym 00000000 

00000000: 53 

00000010: 21 

00000020: 20 

00000030: 10 

00000040: 11 

00000050: 13 

00000060: 14 

00000070: 14 

00000080: 1B 

00000090: 1C ene 
00000040: 1C zB 
000000B0: 25 

20020008: 26 

000000D0: 26 

000000E0: 27 

000000F0: 27 

00000100: 29 

00000110: 2D 

00000120: 2E 

00000130: 30 

00000140: 31 

00000150: 32 

00000160: 33 

00000170: 34 

00000180: 35 

00000190: 36 

00000140: 37 

1610631 2F1181k 30 


Fig. 9.26: Exemple de fichier .SYM d'Oracle RDBMS pour win64 


Donc oui, toutes les tables ont maintenant des éléments 64-bit, méme les offsets de 
chaîne! 


La signature est maintenant OSYMAM64, pour distinguer la plate-forme cible, appa- 
remment. 


C'est fini! 
Voici aussi la bibliothéque qui a des fonctions pour accéder les fichiers .SYM d'Oracle 
RDBMS : GitHub. 
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9.6 Oracle RDBMS : fichiers .MSB-files 


When working toward the solution of a 
problem, it always helps if you know the 
answer. 


Murphy's Laws, Rule of Accuracy 


Ceci est un fichier binaire qui contient les messages d'erreur avec leur numéro cor- 
respondant. Essayons de comprendre son format et de trouver un moyen de les 
extraire. 


Il y a des fichiers de messages d'erreur d'Oracle RDBMS au format texte, donc nous 
pouvons comparer le texte et les fichiers binaires paqués??. 


Ceci est le début du fichier texte ORAUS.MSG avec des commentaires non pertinents 
supprimés: 


Listing 9.11 : Beginning of ORAUS.MSG file without comments 


00000, 00000, "normal, successful completion" 

00001, 00000, "unique constraint (%s.%s) violated" 

00017, 00000, "session requested to set trace event" 

00018, 00000, "maximum number of sessions exceeded" 

00019, 00000, "maximum number of session licenses exceeded" 

00020, 00000, "maximum number of processes (%s) exceeded" 

00021, 00000, "session attached to some other process; cannot switch 2 
S session" 

00022, 00000, "invalid session ID; access denied" 

00023, 00000, "session references process private memory; cannot detach 7 
& session" 

00024, 00000, "logins from more than one process not allowed in single-7 
S process mode" 

00025, 00000, "failed to allocate %s" 

00026, 00000, "missing or invalid session ID" 

00027, 00000, "cannot kill current session" 

00028, 00000, "your session has been killed" 

00029, 00000, "session is not a user session" 

00030, 00000, "User session ID does not exist." 

00031, 00000, "session marked for kill" 


Le premier nombre est le code d'erreur. Le second contient peut-étre des flags sup- 
plémentaires. 


13Les fichiers texte open-source n'existent pas dans Oracle RDBMS pour chaque fichier .MSB, c'est donc 
pourquoi nous allons travailler sur leur format de fichier 
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Maintenant ouvrons le fichier binaire ORAUS.MSB et trouvons ces chaines de teste. 
Et elles y sont: 


Fig. 9.27: Hiew: first block 


Nous voyons les chaînes de texte (celles du début du fichier ORAUS.MSG inclues) 
imbriquées avec d'autres sortes de valeurs binaire. Avec un examen rapide, nous 
pouvons voir que la partie principale du fichier binaire est divisée en bloc de taille 
0x200 (512) octets. 
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Regardons le contenu du premier bloc: 


C:\tmp\oraus.msb 00001400 
00001400: E Bg 
00001410: Ba 4 
00001420: i 
00001430: 

00001440: Bnormal, succ 
00001450: essful completio 
00001460: nunique constrai 
00001470: nt (Xs.Xs) viola 
00001480: tedsession reque 
00001490: sted to set trac 
000014A0: e eventmaximum n 
000014B0: umber of session 
000014C0: s exceededmaximu 
000014D0: m number of sess 
000014E0: ion licenses exc 
000014F0: eededmaximum num 
00001500: ber of processes 
00001510: (%s) exceededse 
00001520: ssion attached t 
00001530: o some other pro 
00001540: cess; cannot swi 
00001550: tch sessioninval 
00001560: id session ID; a 
00001570: ccess deniedsess 
00001580: ion references p 
00001590: rocess private m 
000015A0: emory; cannot de 
000015B0: tach sessionlogi 
1810581 2FI1B1k 2CRVEUR 4/3073 | ing Direct: Table E EC  H 


Fig. 9.28: Hiew: first block 


Ici nous voyons les textes des premiers messages d'erreur. Ce que nous voyons aussi, 
c'est qu'il n'y a pas d'octet à zéro entre les messages d'erreur. Ceci implique que ce 
ne sont pas des chaînes C terminées par null. Par conséquent, la longueur de chaque 
message d'erreur doit étre encodée d'une facon ou d'une autre. Essayons aussi de 
trouver le numéro d'erreur. Le fichier ORAUS.MSG débute par ceci: 0, 1, 17 (0x11), 
18 (0x12), 19 (0x13), 20 (0x14), 21 (0x15), 22 (0x16), 23 (0x17), 24 (0x18)... Nous 
allons trouver ces nombres au début du bloc et les marquer avec des lignes rouge. 
La période entre les codes d'erreur est de 6 octets. 


Ceci implique qu'il y a probablement 6 octets d'information alloués pour chaque 
message d'erreur. 


La premiére valeur 16-bit (OxA ici ou 10) indique le nombre de messages dans 
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chaque bloc: ceci peut étre vérifié en examinant d'autres blocs. En effet: les mes- 
sages d'erreur ont une taille arbitraire. Certains sont plus long, d'autres plus court. 
Mais la taille du bloc est toujours fixée, ainsi, vous ne savez jamais combien de mes- 
sages d'erreur sont stockés dans chaque bloc. 


Comme nous l'avons déjà noté, puisqu'il ne s'agit pas de chaine C terminée par 
null, leur taille doit étre encodée quelque part. La taille de la premiére chaíne «nor- 
mal, successful completion » est de 29 (Ox1D) octets. La taille de la seconde chaîne 
«unique constraint (96s.96s) violated » est de 34 (0x22) octets. Nous ne trouvons pas 
ces valeurs (0x1D ou/et 0x22) dans le bloc. 


Il y a aussi une autre chose. Oracle RDBMS doit déterminer la position de la chaíne 
qu'il y a besoin de charger dans le bloc, exact? La premiére chaine «normal, success- 
ful completion » débute à la position 0x1444 (si nous comptons depuis le début du 
fichier) ou en 0x44 (depuis le début du bloc). La seconde chaíne «unique constraint 
(%s.%s) violated » débute à la position Ox1461 (depuis le début du fichier) ou en 
0x61 (depuis le début du bloc). Ces nombres nous sont quelque peu familier! Nous 
pouvons clairement les voir au début du bloc. 


Donc, chaque bloc de 6 octets est: 
* 16-bit numéro d'erreur; 
* 16-bit à zéro (peut-étre des flags additionnels); 
* position du début de la chaíne de texte dans le bloc courant. 


Nous pouvons rapidement vérifier les autres valeurs et étre sür que notre supposition 
est correcte. Et il y a aussi le dernier bloc «factice» de 6 octets avec un numéro 
d'erreur à zéro et débutant aprés le dernier caractére du dernier message d'erreur. 
Peut-étre est-ce ainsi que la longueur du texte du message est déterminée? Nous 
énumérons juste les blocs de 6 octets pour trouver le numéro d'erreur dont nous 
avons besoin, puis nous obtenons la position de la chaîne de texte, puis la longueur 
de la chaine de texte en cherchant le bloc de 6 octets suivant! De cette facon nous 
déterminons les limites de la chaine! Cette méthode nous permet d'économiser un 
peu d'espace en ne sauvegardant pas la taille de la chaine de texte dans le fichier! 


Il n'est pas possible de dire si ca sauve beaucoup d'espace, mais c'est un truc astu- 
cieux. 
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Revenons à l'entéte de fichier .MSB: 


[EF] Hiew: oraus.msb — 0 "7 
C:Mtmpyoraus.msb BFRO -------- 00000000 
00000000: 01-13 2 

00000010: 00-00 
00000020: 00-00 
00000030: 00-02 
00000040: 00-84 
00000050: 00-14 
00000060: 00-00 
00000070: 00-00 
00000080: 00-00 
00000090: 00-00 
00000040: 00-00 
000000B0: 00-00 
000000C0 : 00-00 
000000D0: 00-00 
000000E0: 00-00 
000000F0: 00-01 
00000100: 00-00 
00000110: 00-00 
00000120: 00-00 
00000130: 00-00 
00000140: 00-00 
00000150: 00-00 
00000160: 00-00 
00000170: 00-00 
00000180: 00-00 
00000190: 00-00 
000001A0: 00-00 
000001B0: 00-00 

| 2ENGBEK GEDYBUR 45 i Es Direct 2 39 1106387 11 


Fig. 9.29: Hiew: entéte de fichier 


Maintenant nous pouvons trouver rapidement le nombre de blocs dans le fichier 
(marqué en rouge). Nous pouvons vérifier d'autres fichiers .MSB et nous voyons que 
c'est vrai pour chacun d'entre eux. 


Il y a de nombreuses autres valeurs, mais nous ne voulons pas les examiner, puisque 
notre job (un utilitaire d'extraction) est fait. 


Si nous devions écrire un générateur de fichier .MSB, nous devrions probablement 
comprendre la signification des autres valeurs. 
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Il y a aussi une table qui vient aprés l'entéte, qui contient probablement des valeurs 
16-bit: 


C:Vtmploraus .msb BFR 
00000800: EE panabiaxa? 4 [474 [4 
00000810: y4wu4$5 , 52595A5G5 
00000820: : N5V5 ]5/15KSri5X5 | 5 
00000830: : L5151565g6meso$6 
00000840: ,6R6[60686] 646 L6 
00000850: 16]686«63616687 
00000860: : 878787!7)71797F7 
00000870: - N7U7^7h7n7u7) 717 
00000880: 8707171747717 
00000890: p7u7€7 - 7E8s8z8u8 
00000840: ! =81 813 Lagogogogo 
000008B0: : #9)9/959>9 
9000080: 
000008D0: 


000008E0: 

000008F0 : e«n«u«n«tic Le F< [Ex 
00000900: À i<S=M>P>U>0>2>> 
00000910: |>—>4>1 >cob> imp 
00000920: i B?8?82#2+242;2D? 
00000930: - M?V?a?1?x?A?M?C? 


00000940: : uj? Bo /AABHALE 
00000950: «Elo lalo Yagaw@c@ 
00000960: - -GGABABABADANAWA 
00000970: | _AFANALAXAHALIARA 
00000980: : 3AnAyAÏA; B^ DDD 
00000990: - | DUF*FBINIVI_JAI 
00000940: ! 3 [2334213243423 2 
000009B0: L333-3-3 [JpJuJ1J 


oh - 
JlUDdli Leave 


Fig. 9.30: Hiew: table last_errnos 


Leurs tailles peuvent étre déterminées visuellement (les lignes rouges sont dessi- 
nées ici). 

En regardant ces valeurs, nous avons trouvé que chaque nombre 16-bit est le dernier 
code d’erreur pour chaque bloc. 

C’est donc ainsi qu’Oracle RDBMS trouve rapidement le message d’erreur: 


* charger la table que nous appellerons last errnos (qui contient le dernier numé- 
ro d'erreur pour chaque bloc); 


* trouver un bloc qui contient le numéro d'erreur que nous cherchons, en assu- 
mant que les codes d'erreur augmentent dans les blocs et aussi dans le fichier; 
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charger le bloc spécifique; 

* énumérer les structures de 6 octets jusqu'à trouver le numéro d'erreur; 
* obtenir la position du premier du bloc de 6 octets courant; 

* obtenir la position du dernier caractére du bloc de 6 octets suivant; 

* charger tous les caractéres du message dans cet intervalle. 


Ceci est un programme C que nous avons écrit qui extrait les fichiers .MSB: begin- 
ners.re. 


Voici aussi les deux fichiers que nous avons utilisé dans l'exemple (Oracle RDBMS 
11.1.0.6) : beginners.re, beginners.re. 


9.6.1 Résumé 


Cette méthode est probablement désuéte pour les ordinateurs moderne. Je suppose 
que ce format de fichier a été développé au milieu des années 80 par quelqu'un 
qui a aussi codé pour les big iron!^ en ayant à l'esprit l'économie d'espace et de 
mémoire. Néanmoins, ca a été une táche intéressante mais facile de comprendre 
un format de fichier propriétaire sans regarder dans le code d'Oracle RDBMS. 


9.7 Exercices 


Essayez de rétro-ingénieurer tous les fichiers binaires de votre jeu favori, fichier des 
meilleurs scores inclus, ressources, etc. 


Il y a aussi des fichiers binaires avec une structure connue: les fichiers utmp/wtmp, 
essayer de comprendre leur structure sans documentation. 


L'entéte EXIF dans les fichiers JPEG est documenté, mais vous pouvez essayer de 
comprendre sa structure sans aide, simplement en prenant des photos à différentes 
heures/dates, lieux, et essayer de trouver la date/heure et position GPS dans les 
données EXIF. Essayez de modifier la position GPS, uploadez le fichier JPEG dans 
Facebook et regardez, comment il va mettre votre photo sur la carte. 


Essayez de patcher toutes les informations dans un fichier MP3 et voyez comment 
réagit votre lecteur de MP3 favori. 


9.8 Pour aller plus loin 


Pierre Capillon - Black-box cryptanalysis of home-made encryption algorithms: a 
practical case study. 


How to Hack an Expensive Camera and Not Get Killed by Your Wife. 


14NDT: Gros ordinateur de type mainframe. 


Chapitre 10 


Dynamic binary 
instrumentation 


Les outils DBI peuvent étre vus comme des débogueurs trés avancés et rapide. 


10.1 Utiliser PIN DBI pour intercepter les XOR 


PIN d'Intel est un outil DBI. Cela signifie qu'il prend un binaire compilé et y insére 
vos instructions, oü vous voulez. 


Essayons d'intercepter toutes les instructions XOR. Elles sont utilisées intensément 
en cryptographie, et nous pouvons essayer de lancer l'archiveur WinRAR en mode 
chiffrement avec l'espoir que des instructions sont effectivement utilisées durant le 
chiffrement. 


Voici le code source de mon outil PIN: https: //beginners.re/paywall/RE4B- source/ 
current-tree//DBI/XOR/files//XOR ins.cpp. 


Le code est presque auto-documenté: il scanne le fichier exécutable en entrée à la re- 
cherche des instructions XOR/PXOR et insére un appel à notre fonction avant chaque. 
La fonction log info() vérifie d'abord si les opérandes sont différents (puisque l'ins- 
truction XOR est souvent utilisée pour effacer simplement un registre, comme XOR 
EAX, EAX), et si ils sont différents, il incrémente un compteur à cette EIP/RIP, afin 
que les statistiques soient collectées. 


J'ai préparé deux fichiers pour tester: test1.bin (30720 octets) et test2.bin (5547752 
octets), je vais les compresser avec RAR avec un mot de passe et voir les différences 
dans les statistiques. 


Vous devez aussi désactiver ASLR !, afin que l'outil PIN rapporte les mémes RIPs que 
dans l'exécutable RAR. 


Maintenant, lancons-le: 


lhttps://stackoverflow.com/q/9560993 
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c:\pin-3.2-81205-msvc-windows\pin.exe -t XOR ins.dll -- rar a -7 
S pLongPassword tmp.rar testl.bin 

c:\pin-3.2-81205-msvc-windows\pin.exe -t XOR ins.dll -- rar a -7 
S pLongPassword tmp.rar test2.bin 


Maintenant voici les statistiques pour test1.bin: 

https://beginners. re/paywall/RE4B- source/current-tree//DBI/XOR/files//XOR _ 
ins.out.testl.... et pour test2.bin: 

https://beginners. re/paywall/RE4B- source/current-tree//DBI/XOR/files//XOR 
ins.out.test2. Jusqu'ici, vous pouvez ignorer toutes les adresses autres que ip=0x1400xxxxx, 
qui sont dans d'autres DLLs. 


Maintenant, regardons la différence: https://beginners. re/paywall/RE4B- source/ 
current-tree//DBI/XOR/files//XOR ins.diff. 


Certaines instructions XOR sont exécutées plus souvent pour test2.bin (qui est plus 
gros) que pour testl.bin (qui est plus petit). Donc elles sont clairement liées à la 
taille du fichier! 


Le premier bloc de différence est: 


« ip-0x140017b21 count=0xd84 
< 1p=0x140017b48 count=0x81f 
« ip=0x140017b59 count=0x858 
< ip=0x140017b6a count=0xc13 
« ip=0x140017b7b count=0xefc 
« ip=0x140017b8a count=0xefd 
< ip=0x140017b92 count=0xb86 
< ip-0x140017bal count=0xf01 
> ip-0x140017b21 count=0x9eab5 
> ip-0x140017b48 count=0x79863 
> ip-0x140017b59 count=0x862e8 
> ip-0x140017b6a count=0x99495 
> ip=0x140017b7b count=0xa891c 
> ip-0x140017b8a count=0xa89f4 
> ip=0x140017b92 count=0x8ed72 
> ip=0x140017bal count=0xa8a8a 


C'est en effet une sorte de boucle à l'intérieur de RAR.EXE: 


.text:0000000140017B21 loc 140017B21: 


.text:0000000140017B21 xor rlid, [rbx] 
.text:0000000140017B24 mov r9d, [rbx+4] 
.text:0000000140017B28 add rbx, 8 
.text:0000000140017B2C mov eax, r9d 
.text:0000000140017B2F shr eax, 18h 
.text:0000000140017B32 movzx edx, al 
.text:0000000140017B35 mov eax, r9d 
.text:0000000140017B38 shr eax, 10h 
.text:0000000140017B3B movzx ecx, al 
.text:0000000140017B3E mov eax, r9d 


.text:0000000140017B41 shr eax, 8 
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.text:0000000140017B44 mov r8d, [rsi+rdx*4] 
.text:0000000140017B48 xor r8d, [rsi+rcx*4+400h] 
.text:0000000140017B50 movzx ecx, al 
.text:0000000140017B53 mov eax, riid 
.text:0000000140017B56 shr eax, 18h 
.text:0000000140017B59 xor r8d, [rsi+rcx*4+800h] 
.text:0000000140017B61 movzx ecx, al 
.text:0000000140017B64 mov eax, rlld 
.text:0000000140017B67 shr eax, 10h 
.text:0000000140017B6A xor red, [rsi+rcx*4+1000h] 
.text:0000000140017B72 movzx ecx, al 
.text:0000000140017B75 mov eax, rlld 
.text:0000000140017B78 shr eax, 8 
.text:0000000140017B7B xor r8d, [rsi+rcx*4+1400h] 
.text:0000000140017B83 movzx ecx, al 
.text:0000000140017B86 movzx eax, r9b 
.text:0000000140017B8A xor red, [rsi+rcx*4+1800h] 
.text:0000000140017B92 xor r8d, [rsi+rax*4+0C00h] 
.text:0000000140017B9A movzx eax, rllb 
.text:0000000140017B9E mov rlld, r8d 
.text:0000000140017BA1 xor rlld, [rsi+rax*4+1C00h] 
.text:0000000140017BA9 sub rdi, 1 
.text:0000000140017BAD jnz loc 140017B21 


Que fait-elle? Aucune idée à ce stade. 


La suivante: 


< ip=0x14002c4f1 count=0x4fce 


> ip=0x14002c4f1 count=0x4463be 


Ox4fce est 20430, qui est proche de la taille de test1.bin (30720 octets). 0x4463be 
est 4481982, qui est proche de la taille de test2.bin (5547752 octets). Par égal, mais 
proche. 


Ceci est un morceau de code avec cette instruction XOR: 


. text: 000000014002C4EA loc 14002C4EA: 


. text: 000000014002C4EA movzx eax, byte ptr [r8] 

. text :000000014002C4EE shl ecx, 5 

. text: 000000014002C4F1 xor ecx, eax 

. text :000000014002C4F3 and ecx, 7FFFh 

. text :000000014002C4F9 cmp [rll+rcx*4], esi 

. text :000000014002C4FD jb short loc 14002C507 
.text:000000014002C4FF cmp [r1l+rcx*4], rl0d 
.text:000000014002C503 ja short loc 14002C507 
.text:000000014002C505 inc ebx 


Le corps de la boucle peut étre écrit comme: 


state 


= input byte ^ (state<<5) € Ox7FFF}. 
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state est ensuite utilisé comme un index dans une table. Est-ce une sorte de CRC? ? 
Je ne sais pas, mais ca pourrait étre une routine effectuant une somme de contróle. 
Ou peut-étre une routine CRC optimisée? Une idée? 


Le bloc suivant: 


« ip-0x14004104a 
< ip=0x140041057 


> ip-0x14004104a 
> ip-0x140041057 


count=0x367 
count=0x367 


count=0x24193 
count=0x24193 


. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 
. text 


:0000000140041039 loc_140041039: 
:0000000140041039 
:000000014004103C 
:0000000140041040 
:0000000140041044 
:0000000140041048 
:000000014004104A 
:000000014004104E 
:000000014004104E 
:000000014004104E 
:0000000140041053 
:0000000140041057 
:000000014004105B 
:000000014004105F 
:0000000140041061 
:0000000140041065 
:0000000140041069 
:0000000140041069 
:0000000140041069 
:000000014004106D 
:0000000140041071 
:0000000140041076 
:000000014004107A 
:000000014004107C 


loc_14004104E: 


loc 140041069: 


movdqu 
movsxd 
pxor 
cmp 
jte 
lea 
lea 


movdqu 
lea 
aesenc 
sub 
jnz 


rax, r10 

r10, 10h 

byte ptr [rcx+1], 0 
xmm0, xmmword ptr [rax] 
short loc 14004104E 
xmmO, xmml 


xmml1, xmmword ptr [rcx+18h] 
r8, dword ptr [rcx+4] 

xmml, xmm0 

rad, 1 

short loc 14004107C 

rdx, [rcx+28h] 

r9d, [r8-1] 


xmm0, xmmword ptr [rdx] 


rdx, [rdx+10h] 
xmml, xmm0 
r9, 1 


short loc 140041069 


Ce morceau posséde les instructions PXOR et AESENC (la derniére est une instruction 
de chiffrement AES?). Donc oui, nous avons trouvé une fonction de chiffrement, RAR 
utilise AES. 


Il y a ensuite un autre gros bloc d'instructions XOR presque contigus: 


« ip=0x140043e10 count=0x23006 


> ip-0x140043e10 count=0x23004 
499c510 
< ip=0x140043e56 count=0x22ffd 


> ip-0x140043e56 count=0x23002 


2Cyclic redundancy check 
3Advanced Encryption Standard 
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Mais le compteur n'est pas trés différent pendant la compression/chiffrement de 
test1.bin/test2.bin. Qu'y a-t-il à ces adresses? 


.text:0000000140043E07 xor ecx, rod 
.text:0000000140043E0A mov rlld, eax 

. text :0000000140043E0D and ecx, rl0d 

. text: 0000000140043E10 xor ecx, r8d 
.text:0000000140043E13 rol eax, 8 
.text:0000000140043E16 and eax, esi 
.text:0000000140043E18 ror rild, 8 
.text:0000000140043E1C add edx, 5A827999h 
.text:0000000140043E22 ror r10d, 2 
.text:0000000140043E26 add r8d, 5A827999h 
.text:0000000140043E2D and rlid, r12d 
.text:0000000140043E30 or rlld, eax 

. text :0000000140043E33 mov eax, ebx 


Googlons la constante 5A827999h... ceci ressemble à du SHA-1! mais pourquoi RAR 
utiliserait-il SHA-1 pendant le chiffrement? 


Voici la réponse: 


In comparison, WinRAR uses its own key derivation scheme that requires (7 
y password length * 2 + 11)*4096 SHA-1 transformations. 'Thats why it 7 
V takes longer to brute-force attack encrypted WinRAR archives. 


(http://www. tomshardware.com/reviews/password- recovery-gpu, 2945-8. html 


) 


C'est la génération de la clef: le mot de passe entré est hashé plusieurs fois et le 
hash est utilisé comme clef AES. C'est pourquoi nous voyons que le comptage de 
l'instruction XOR est presque inchangé lorsque nous passons au fichier de test plus 
gros. 


C'est tout ce qu'il faut faire, ca m'a pris quelques heures d'écrire cet outil et d'obtenir 
au moins 3 éléments: 1) c'est probablement une somme de contróle; 2) chiffrement 
AES; 3) calcul de somme SHA-1. La premiere fonction est encore un mystére pour 
moi. 


Cependant, ceci est impressionnant, car je ne me suis pas plongé dans le code de 
RAR (qui est propriétaire, bien sûr). Je n'ai méme pas jeté un coup d'œil dans le code 
source de UnRAR (qui est disponible). 


Les fichiers, incluant les fichiers de test et l'exécutable RAR que j'ai utilisé (win64, 
5.40) : 
https://beginners.re/paywall/REAB- source/current-tree//DBI/XOR/files/. 


10.2 Cracker Minesweeper avec PIN 


Dans ce livre, j'ai expliqué comment cracker Minesweeper pour Windows XP: 8.4 on 
page 1047. 
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Le Minesweeper de Windows Vista et 7 est différent: il a probablement été (r)écrit 
en C++, et l'information de la case n'est maintenant plus stockée dans un tableau 
global, mais plutót dans des blocs du heap alloués par malloc. 


Ceci est un cas où nous pouvons essayer l'outil PIN DBI. 


10.2.1 Intercepter tous les appels à rand() 


Tout d'abord, puisque Minesweeper dispose les mines aléatoirement, il doit appe- 
ler rand() ou une fonction similaire. Essayons d'intercepter tous les appels à rand() : 
https://beginners.re/paywall/REAB- source/current-tree//DBI/minesweeper/ 
minesweeperl.cpp. 


Nous pouvons maintenant le lancer: 


c:\pin-3.2-81205-msvc-windows\pin.exe -t minesweeperl.dll -- C:\PATH\TO\/ 
\ MineSweeper.exe 


Durant le démarrage, PIN cherche tous les appels a la fonction rand() et ajoute un 
hook juste aprés chaque appel. Le hook est la fonction RandAfter() que nous avons 
défini: elle logue la valeur et l'adresse de retour. Voici un log que j'ai obtenu en lan- 
cant la configuration 9*9 standard (10 mines) : https://beginners. re/paywall/ 
RE4B- source/current-tree//DBI/minesweeper/minesweeperl.out.10mines. La 
fonction rand() a été appelée de nombreuses fois depuis différents endroits, mais 
a été appelée depuis 0x10002770d exactement 10 fois. J’ai changé la configura- 
tion de Minesweeper a 16*16 (40 mines) et rand() a été appelée 40 fois depuis 
0x10002770d. Donc oui, c'est ce que l'on cherche. Lorsque je charge mineswee- 
per.exe (depuis Windows 7) dans IDA et une fois que le PDB est récupéré depuis le 
site web de Microsoft, la fonction qui appelle rand() en 0x10002770d est appelée 
Board::placeMines(). 


10.2.2 Remplacer les appels a rand() par notre function 


Essayons maintenant de remplacer la fonction rand() avec notre version, qui ren- 
voie toujours zéro: https: //beginners. re/paywall/RE4B- source/current-tree/ 
/DBI/minesweeper/minesweeper2.cpp. Durant le démarrage, PIN remplace tous les 
appels à la fonction rand() par des appels à notre fonction, qui écrit dans le log et 
renvoie zéro. Ok, je l'ai lancé et ai cliqué sur la case la plus en haut à gauche. 
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[^ ineswceper TES 


Game Help 


2| 
al 
al 
al 
dl 
al 
al 
O 


Oui, contrairement á Minesweeper de Windows XP, les mines sont placées aléatoi- 
rement aprés que l'utilisateur ai cliqué sur une case, afin de garantir qu'il n'y a pas 
de mine sur la premiére case cliquée par l'utilisateur. Donc Minesweeper a placé les 
mines dans des cases autres que celle la plus en haut à gauche (oü j'ai cliqué). 


Maintenant j'ai cliqué sur la case la plus en haut à droite: 


=ioix 


Game Help 


EEEEEFFF 
lalalala 
all al al al 
[212 ath al lal 


Ceci peut-étre une sorte de blague? Je ne sais pas. 


J'ai cliqué sur la 5éme case (droite du milieu) de la 1ére ligne: 
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Game Help 


C'est bien, car Minesweeper peut effectuer un placement correct méme avec un 
PRNG aussi mauvais! 


10.2.3 Regarder comment les mines sont placées 


Comment pouvons-nous obtenir des informations sur où les mines sont placées? Le 
résultat de rand() semble étre inutile: elle renvoie zéro à chaque fois, mais Mines- 
weeper a réussi à placer les mines dans des cases différentes, quoique, alignées. 


Ce Minesweeper est aussi écrit dans la tradition C++, donc il n'a pas de tableau 
global. 


Mettons-nous dans la peau du programmeur. Il doit y avoir une boucle comme: 


for (int i; i«mines total; i++) 
1 

// get coordinates using rand() 

// put a cell: in other words, modify a block allocated in heap 
}; 


Comment pouvons-nous obtenir des information sur le bloc de qui est modifié à la 
2nde étape? Ce que nous devons faire: 1) suivre toutes les allocations dans la heap 
en interceptant malloc()/realloc()/free(). 2) suivre toutes les écritures en mémoire 
(lent). 3) suivre les appels à rand(). 


Maintenant l'algorithme: 1) suivre tous les blocs du heap qui sont modifiés entre le 
ler et le 2nd appel à rand() depuis 0x10002770d; 2) à chaque fois qu'un bloc du 
heap est libéré, afficher son contenu. 


Suivre toutes les écritures en mémoire est lent, mais aprés le 2nd appel à rand(), 
nous n'avons plus besoin de les suivre (puisque nous avons déjà obtenu une liste de 
blocs intéressants à ce point), donc nous arrétons. 


Maintenant le code: https: //beginners.re/paywall/RE4B-source/current-tree/ 
/DBI/minesweeper/minesweeper3.cpp. 


Il s'avère que seulement 4 blocs de heap sont modifiés entre les deux premiers 
appels à rand(), voici à quoi ils ressemblent: 
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free (0x20aa6360) 

free(): we have this 

0x20AA6360: 36 00 00 
IR 

0x20AA6370: 
Mas ad 

0x20AA6380: 
" n 


06 00 00 
pr " 
46 00 00 


free(0x20af9d10) 

free(): we have this 

0x20AF9D10: OA 00 00 
REDIMERE " 

0x20AF9D20: 60 63 AA 
Cs LL 


free (0x20b28b20) 


free(): we 


0x20B28B20: 
Mabe are a eoe he ale RS 
0x20B28B30: 


have this 
02 00 00 


Sa oaa Dar an CO CE dan E 


0x20B28B40: 


0x20B28B50: 


a to DE » 


0x20B28B60: 
GS bo do kc tebe 
0x20B28B70: 


Moy (cla ES a de ace " 


0x20B28B80: 
EE 
0x20B28B90: 


% 


Orana 


Go. 
0x20B28BA0: 


0x20B28BBO: 


CO 


0x20B28BC0: 
Sor... 
0x20B28BDO0: 
M 8S Ls 
0x20B28BE0: 
da 
0x20B28BF0: 


Me ss 
0x20B28C00: 


ones 
0x20B28C10: 


in 
00 


in 
00 


our records, size=0x28 
00 00-2D 00 00 00 29 00 


00 00-35 00 00 00 19 00 


00 00- 


our records, size=0x18 
00 00-0A 00 00 00 00 00 


00 00- 


our records, size=0x140 
00 00 00 05 00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00-04 


00-0C 


00-10 


00-14 


00-18 


00-1D 


00-21 


00-25 


00-2A 


00-2F 


00-33 


00-3A 


00-3E 


00-42 


00-47 


00 -4B 


00 00 00 OD 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


11 


15 


1A 


1E 


22 


26 


2B 


30 


34 


3B 


3F 


43 


48 


4C 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 


00 
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Ge tical 

0x20B28C20: 4D 00 00 00 4F 00 00 00-50 00 00 00 50 00 00 00 "M...0...P...P7 
C" 

0x20B28C30: 50 00 00 00 50 00 00 00-50 00 00 00 50 00 00 00 "P...P...P...P7 
NEL 

0x20B28C40: 50 00 00 00 50 00 00 00-50 00 00 00 50 00 00 00 "P...P...P...P7 
ae 

0x20B28C50: 50 00 00 00 00 00 00 00-00 00 00 OO 00 00 OO 00 "PY 
ra do Soares k 

free(0x20af9cf0) 

free(): we have this block in our records, size=0x18 

Ox20AF9CFO: 43 00 00 00 50 00 00 00-10 00 00 00 20 00 74 00 "C...P....... EZ 
S t." 

Ox20AF9D00: 20 8B B2 20 00 00 00 00- ede EEE 2 
g " 


Nous voyons facilement que les plus gros blocs (avec une taille de 0x28 et 0x140) 
sont juste des tableaux de valeurs jusqu'à « 0x50. Attendez... 0x50 est 80 en repré- 
sentation décimale. et 9*9=81 (configuration standard de Minesweeper). 


Aprés une rapide investigation, j'ai trouvé que chaque élément 32-bit est en fait les 
coordonnées d'une case. Une case est représentée en utilisant un seul nombre, c'est 
un nombre dans un tableau-2D. Ligne et colonne de chaque mine sont décodées 
comme ceci: row=n / WIDTH; col=n 96 HEIGHT; 


Lorsque j'ai essayé de décoder ces deux blocs les plus gros, j'ai obtenu ces cartes 
de case: 


try to dump cells(). unique elements-0xa 
* 


try to dump cells(). unique elements-0x44 
EES E E 
pa REE 
ERES ok 
KK OK OK K K OK K K 
AAA KKK 
ARA 
de RAR 
ee ck 
RARFMX FT 
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Il semble que le premier bloc soit juste une liste des mines placées, tandis que le 
second bloc est une liste des cases libres, mais le second semble quelque peu désyn- 
chroniser du premier, et une version inversée du premier ne coincide que partielle- 
ment. Néanmoins, la première carte est correcte - nous pouvons jeter un coup d'œil 
dans le fichier de log alors que Minesweeper est encore chargé et presque toutes 
les cases sont cachées, et cliquer tranquillement sur les cases marquées d'un point 
ici. 

Il semble donc que lorsque l'utilisateur clique pour | premiére fois quelque part, Mi- 
nesweeper place les 10 mines, puis détruit le bloc avec leurs liste (peut-étre copie-t-il 
toutes les données dans un autre bloc avant?), donc nous pouvons les voir lors de 
l'appel à free(). 


Un autre fait: la méthode Array<NodeType>::Add(NodeType) modifie les blocs que 

nous avons observé, et est appelée depuis de nombreux endroits, Board::placeMines() 
incluse. Mais c'est cool: je ne suis jamais allé dans les détails, tout a été résolu sim- 
plement en utilisant PIN. 


Les fichiers: https: //beginners.re/paywall/RE4B-source/current-tree//DBI/ 
minesweeper. 


10.2.4 Exercice 


Essayez de comprendre comment le résultat de rand() est converti en coordonnée(s). 
Pour blaguer, faite que rand() renvoie des résultats tels que les mines soient placées 
en formant un symbole ou une figure. 


10.3 Compiler Pin 


Compiler Pin pour Windows peut s'avérer délicat. Ceci est ma recette qui fonctionne. 
* Décompacter le dernier Pin, disons, C:\pin-3.7\ 
e Installer le dernier Cygwin, dans, disons, c: Ncygwin64 


* Installer MSVC 2015 ou plus récent. 


Ouvrir le fichier C:\pin-3.7\source\tools\Config\makefile.default. rules, 
remplacer mkdir -p $6 par /bin/mkdir -p $6 


* (Si nécessaire) dans C:\pin-3.7\source\tools\SimpleExamples\makefile. rules, 
ajouter votre pintool à la liste TEST TOOL ROOTS. 


Ouvrir "VS2015 x86 Native Tools Command Prompt". Taper: 


cd c:\pin-3.7\source\tools\SimpleExamples 
c:\cygwin64\bin\make all TARGET=ia32 


Maintenant les outils pintools sont dans c:\pin-3.7\source\tools\SimpleExamples\obj -ia32 


* Pour winx64, utiliser "x64 Native Tools Command Prompt” et lancer: 
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c:\cygwin64\bin\make all TARGET=intel64 


* Lancer pintool: 


c:\pin-3.7\pin.exe -t C:\pin-3.7\source\tools\SimpleExamples\obj -1a32N7 
& XOR ins.dll -- program.exe arguments 


10.4 Pourquoi "instrumentation"? 


Peut-étre que c'est un terme de profilage de code. Il y a au moins deux méthodes: 
1) "échantillonnage": vous rentrez dans le code se déroulant autant de fois que pos- 
sible (des centaines par seconde), et regardez, où en est l'exécution à ce moment; 
2) "instrumentation": le code compilé est intercalé avec de l'autre code, qui peut 


incrémenter des compteurs, etc. 
Peut-étre que les outils DBI ont hérités du terme? 


Chapitre 11 


Autres sujets 


11.1 Utiliser IMUL au lieu de MUL 


Un exemple comme listado.3.23.2 oú deux valeurs non signées sont multipliées com- 
pile en listado.3.23.2 où IMUL est utilisé à la place de MUL. 


Ceci est une propriété importante des instructions MUL et IMUL. Tout d'abord, les 
deux produisent une valeur 64-bit si deux valeurs 32-bit sont multipliées, ou une 
valeur 128-bit si deux valeurs 64-bit sont multipliées (le plus grand produit dans un 
environnement 32-bit est 

Oxffffffff*Oxffffffff-Oxfffffffe00000001). Mais les standards C/C++ n'ont 
pas de moyen d'accéder à la moitié supérieure du résultat, et un produit a toujours la 
méme taille que ses multiplicandes. Et les deux instructions MUL et IMUL fonctionnent 
de la méme maniére si la moitié supérieure est ignorée, i.e, elles produisent le méme 
résultat dans la partie inférieure. Ceci est une propriété importante de la facon de 
représenter les nombre en «complément à deux ». 


Donc, le compilateur C/C++ peut utiliser indifféremment ces deux instructions. 


Mais IMUL est plus flexible que MUL, car elle prend n'importe quel(s) registre(s) comme 
source, alors que MUL nécessite que l'un des multiplicandes soit stocké dans le re- 
gistre AX/EAX/RAX Et méme plus que ca: MUL stocke son résultat dans la paire EDX: EAX 
en environnement 32-bit, ou RDX:RAX dans un 64-bit, donc elle calcule toujours le 
résultat complet. Au contraire, il est possible de ne mettre qu'un seul registre de 
destination lorsque l'on utilise IMUL, au lieu d'une paire, et alors le CPU calculera 
seulement la partie basse, ce qui fonctionne plus rapidement [voir Torborn Granlund, 
Instruction latencies and throughput for AMD and Intel x86 processors! ]. 


Cela étant considéré, les compilateurs C/C++ peuvent générer l'instruction IMUL 
plus souvent que MUL. 


Néanmoins, en utilisant les fonctions intrinséques du compilateur, il est toujours pos- 
sible d'effectuer une multiplication non signée et d'obtenir le résultat complet. Ceci 
est parfois appelé multiplication étendue. MSVC a une fonction intrinséque pour ceci, 


lhttp://yurichev.com/mirrors/x86- timing.pdf 
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appelée _emul? et une autre: umul128?. GCC offre le type de données  int128, et 
dans le cas de multiplicandes 64-bit, ils sont déjà promus en 128-bit, puis le produit 
est stocké dans une autre valeur _int128, puis le résultat est décalé de 64 bits à 
droite, et vous obtenez la moitié haute du résultat^. 


11.1.1 Fonction MulDiv() dans Windows 


Windows possède la fonction MulDiv()°, fonction qui fusionne une multiplication et 
une division, elle multiplie deux entiers 32-bit dans une valeur 64-bit intermédiaire et 
la divise par un troisiéme entier 32-bit. C'est plus facile que d'utiliser deux fonctions 
intrinséques, donc les développeurs de Microsoft ont écrit une fonction spéciale pour 
cela. Et il semble que ca soit une fonction trés utilisée, à en juger par son utilisation. 


11.2 Modification de fichier exécutable 


11.2.1 code x86 


Les táches de modification courantes sont: 


* Une des táches la plus fréquente est de désactiver une instruction en l'écrasant 
avec des octets 0x90 (NOP). 


* Les branchements conditionnels qui utilisent un code instruction tel que 74 xx 
(JZ), peuvent étre réécrits avec deux instructions NOP. 


Une autre technique consiste à désactiver un branchement conditionnel en 
écrasant le second octet avec la valeur 0 (jump offset). 


* Une autre táche courante consiste à faire en sorte qu'un branchement condi- 
tionnel soit effectué systématiquement. On y parvient en remplacant le code 
instruction par OxEB qui correspond à l'instruction JMP. 


* ['exécution d'une fonction peut étre désactivée en remplacant le premier octet 
par RETN (0xC3). Les fonctions dont la convention d'appel est stdcall (6.1.2 
on page 953) font exception. Pour les modifier, il faut déterminer le nombre 
d'arguments (par exemple en trouvant une instruction RETN au sein de la fonc- 
tion), puis en utilisant l'instruction RETN accompagnée d'un argument sur deux 
octets (0xC2). 


Il arrive qu'une fonction que l'on a désactivée doive retourner une valeur 0 ou 
1. Certes on peut utiliser MOV EAX, 0 ou MOV EAX, 1, mais cela occupe un peu 
trop d'espace. 

Une meilleure approche consiste à utiliser XOR EAX, EAX (2 octets 0x31 0xC0) 
ou XOR EAX, EAX / INC EAX (3 octets 0x31 0xC0 0x40). 


Un logiciel peut étre protégé contre les modifications. Le plus souvent la protection 
consiste à lire le code du programme (en mémoire) et à en calculer une valeur de 


?https://msdn.microsoft.com/en-us/library/d2s81xt0(v-vs.80) .aspx 
3https://msdn.microsoft.com/library/3dayytw9%28v=vs . 1005529 . aspx 

^Exemple: http://stackoverflow.com/a/13187798 
Shttps://msdn.microsoft.com/en-us/library/windows/desktop/aa383718(v=vs.85) .aspx 
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contróle. Cette technique nécessite que la protection lise le code avant de pouvoir 
agir. Elle peut donc étre détectée en positionnant un point d'arrét déclenché par la 
lecture de la mémoire contenant le code. 


tracer posséde l'option BPM pour ce faire. 


La partie du fichier au format PE qui contient les informations de relogement (6.5.2 
on page 989) ne doivent pas étre modifiées par les patchs car le chargeur Windows 
risquerait d'écraser les modifications apportées. (Ces parties sont présentées sous 
forme grisées dans Hiew, par exemple: fig.1.21). 


En dernier ressort, il est possible d'effectuer des modifications qui contournent les 
relogements, ou de modifier directement la table des relogements. 


11.3 Statistiques sur le nombre d'arguments d'une 
fonction 


J'ai toujours été intéressé par le nombre moyen d'arguments d'une fonction. 


J'ai donc analysé un bon nombre de DLLs 32 bits de Windows7 

(crypt32.dll, mfc71.dll, msvcr100.dll, shell32.dll, user32.dll, d3d11.dll, mshtml.dll, 

msxml6.dil, sqinclil1.dil, wininet.dll, mfc120.dll, msvbvm60.dll, ole32.dll, themeui.dll, 
wmp.dll) (parce qu'elles utilisent la convention d'appel stdcall et qu'il est donc facile 

de retrouver les instructions RETN X en utilisant la commande grep sur leur code 

une fois celui-ci désassemblé). 


* no arguments: « 2996 
e 1 argument: x 23% 

* 2 arguments: « 2096 
* 3 arguments: « 1196 
* 4 arguments: « 7% 

* 5 arguments: « 396 

* 6 arguments: « 296 

* 7 arguments: « 196 
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Fig. 11.1: Statistiques du nombre d'arguments moyen d'une fonction 


Ces nombres dépendent beaucoup du style de programmation et peuvent s'avérer 
tres différents pour d'autres logiciels. 


11.4 Fonctions intrinseques du compilateur 


Les fonctions intrinséques sont spécifiques à chaque compilateur. Ce ne sont pas des 
fonctions que vous pouvez retrouver dans une bibliothéque. Le compilateur génére 
une séquence spécifique de code machine lorsqu'il rencontre la fonction intrinséque. 
Le plus souvent, il s'agit d'une pseudo fonction qui correspond à une instruction d'un 
CPU particulier. 


Par exemple, il n'existe pas d'opérateur de décalage cyclique dans les langages 
C/C++. La plupart des CPUs supportent cependant des instructions de ce type. Pour 
faciliter la vie des programmeurs, le compilateur MSVC propose de telles pseudo 
fonctions rot/() and _rotr()° qui sont directement traduites par le compilateur vers 
les instructions x86 ROL/ROR. 


Les fonctions intrinséques qui permettent de générer des instructions SSE en sont 
un autre exemple. 


La liste compléte des fonctions intrinséques proposées par le compilateur MSVC fi- 
gurent dans le MSDN. 


SMSDN 
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11.5 Anomalies des compilateurs 


11.5.1 Oracle RDBMS 11.2 et Intel C++ 10.1 


Le compilateur Intel C++ 10.1, qui a été utilisé pour la compilation de Oracle RDBMS 
11.2 pour Linux86, émettait parfois deux instructions JZ successives, sans que la 
seconde instruction soit jamais référencée. Elle était donc inutile. 


Listing 11.1 : kdli.o from libserver11.a 


.text:08114CF1 loc 8114CF1: 
CODE XREF: PGOSF539 kdlimemSer+89A 

.text:08114CF1 ; PGOSF539 kdlimemSer+3994 
.text:08114CF1 8B 45 08 mov eax, [ebp+arg 0] 
.text:08114CF4 OF B6 50 14 movzx edx, byte ptr [eax+14h] 
.text:08114CF8 F6 C2 01 test di, 1 
.text:08114CFB OF 85 17 08 00 00 jnz loc 8115518 
.text:08114D01 85 C9 test ecx, ecx 
.text:08114D03 OF 84 8A 00 00 00 jz loc 8114D93 
.text:08114D09 OF 84 09 08 00 00 jz loc 8115518 
.text:08114D0F 8B 53 08 mov edx, [ebx+8] 
.text:08114D12 89 55 FC mov [ebp+var 4], edx 
.text:08114D15 31 CO xor eax, eax 
.text:08114D17 89 45 F4 mov [ebp-var C], eax 
.text:08114D1A 50 push eax 
.text:08114D1B 52 push edx 
.text:08114D1C E8 03 54 00 00 call len2nbytes 
.text:08114D21 83 C4 08 add esp, 8 

Listing 11.2 : from the same code 
.text:0811A2A5 loc 811A2A5: ; CODE XREF: kdliSerLengths+11C 
.text:0811A2A5 ; kdliSerLengths+1C1 
.text:0811A2A5 8B 7D 08 mov edi, [ebp+arg 0] 
.text:0811A2A8 8B 7F 10 mov edi, [edi+10h] 
.text:0811A2AB OF B6 57 14 movzx edx, byte ptr [edi+14h] 
.text:0811A2AF F6 C2 01 test di, 1 
.text:0811A2B2 75 3E jnz short loc 811A2F2 
.text:0811A2B4 83 EO 01 and eax, 1 
.text:0811A2B7 74 1F jz short loc 811A2D8 
.text:0811A2B9 74 37 jz short loc 811A2F2 
.text:0811A2BB 6A 00 push 0 
.text:0811A2BD FF 71 08 push dword ptr [ecx+8] 
.text:0811A2C0 E8 5F FE FF FF call len2nbytes 


Il s'agit probablement d'un bug du générateur de code du compilateur qui ne fut pas 
découvert durant les tests de celui-ci car le code produit fonctionnait conformément 
aux résultats attendus. 


Un autre exemple tiré d'Oracle RDBMS 11.1.0.6.0 pour win32. 


.text:0051FBF8 85 CO 
.text:0051FBFA OF 84 8F 00 00 00 
.text:0051FC00 74 1D 


test 
jz 
jz 


eax, eax 
loc 51FC8F 
short loc 51FCIF 
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11.5.2 MSVC 6.0 


Je viens juste de trouver celui-ci dans un vieux fragment de code : 


fabs 
fild 
fabs 
fxch 
fxch 
faddp 
fcomp 
fnstsw 
test 
jz 


[esp+50h+var_34] 


St(1) ; premiére instruction 
st(1) ; seconde instruction 
st(1), st 

[esp+50h+var_3C] 

ax 

ah, 41h 

short loc_100040B7 


La premiére instruction FXCH intervertit les valeurs de ST(0) et ST(1). La seconde 
effectue la méme opération. Combinées, elles ne produisent donc aucun effet. Cet 
extrait provient d'un programme qui utilise la bibliothèque MFC42.dll, il a donc dû 
être compilé avec MSVC 6.0 ou 5.0 ou peut-être même MSVC 4.2 qui date des années 


90. 


Cette paire d'instructions ne produit aucun effet, ce qui expliquerait qu'elle n'ait pas 
été détectée lors des tests du compilateur MSVC. Ou bien j'ai loupé quelque chose 


11.5.3 ftol2() dans MSVC 2012 


Je viens de trouver ceci dans la fonction ftol2() de la bibliothéque C/C++ standard 


(routine de conversion float-to-long) de Microsoft Visual Studio 2012. 


public  ftol2 


. ftol2 proc near 
push ebp 
mov ebp, esp 
sub esp, 20h 
and esp, OFFFFFFFOh 
fld st 
fst dword ptr [esp+18h] 
fistp | qword ptr [esp+10h] 
fild qword ptr [esp+10h] 
mov edx, [esp+18h] 
mov eax, [esp+10h] 
test eax, eax 
jz short integer QnaN or zero 


arg is not integer QnaN: 
fsubp 
test 
jns 
fstp 
mov 
xor 
add 


st(1), st 

edx, edx 

short positive 
dword ptr [esp] 
ecx, [esp] 

ecx, 80000000h 
ecx, 7FFFFFFFh 
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adc eax, 0 

mov edx, [esp+14h] 

adc edx, 0 

jmp short localexit 
positive: 

fstp dword ptr [esp] 

mov ecx, [esp] 

add ecx, 7FFFFFFFh 

sbb eax, 0 

mov edx, [esp+14h] 

sbb edx, 0 

jmp short localexit 


integer QnaN or zero: 


mov edx, [esp+14h] 
test edx, 7FFFFFFFh 
jnz short arg is not integer QnaN 


fstp dword ptr [esp+18h] ; first 
fstp dword ptr [esp+18h] ; second 


localexit: 
leave 
retn 
. ftol2 endp 


Notez les deux FSTP-s (stocker un float avec pop) identiques à la fin. D'abord, j'ai 
cru qu'il s'agissait d'une anomalie du compilateur (je collectionne de tels cas tout 
comme certains collectionnent les papillons), mais il semble qu'il s'agisse d'un mor- 
ceau d'assembleur écrit à la main, dans msvcrt.lib il y a un fichier objet avec cette 
fonction dedans et on peut y trouver cette chaîne: 

f:\dd\vctools\crt bld\SELF X86\crt\prebuild\tran\i386\ftol2.asm— qui est 
sans doute un chemin vers le fichier sur l'ordinateur du développeur oü msvcrt.lib a 
été généré. 


Donc, bogue, typo induite par l'éditeur de texte ou fonctionnalité? 


11.5.4 Résumé 


Des anomalies constatées dans d'autres compilateurs figurent également dans ce 
livre: 1.28.2 on page 405, 3.10.3 on page 630, 3.18.7 on page 684, 1.26.7 on page 386, 
1.18.4 on page 194, 1.28.5 on page 428. 


Ces cas sont exposés dans ce livre afin de démontrer que ces compilateurs com- 
portent leurs propres erreurs et qu'il convient de ne pas toujours se torturer le cer- 
veau en tentant de comprendre pourquoi le compilateur a généré un code aussi 
étrange. 
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11.6 Itanium 


Bien qu'elle n'ai pas réussi à percer, l'architecture Intel Itanium (1464) est trés inté- 
ressante. 


Là oü les CPUs OOE réarrangent les instructions afin de les exécuter en paralléle, 
l'architecture EPIC/ a constitué une tentative pour déléguer cette décision au com- 
pilateur. 


Les compilateurs en question étaient évidemment particulièrement complexes. 


Voici un exemple de code pour l'architecture |A64 qui implémente un algorithme de 
chiffrage simple du noyau Linux: 


Listing 11.3 : Linux kernel 3.2.0.4 


define TEA ROUNDS 32 
#define TEA DELTA 0x9e3779b9 


static void tea_encrypt(struct crypto tfm *tfm, u8 *dst, const u8 *src) 
{ 

u32 y, z, n, sum = Q; 

u32 k0, k1, k2, k3; 

struct tea ctx *ctx = crypto tfm ctx(tfm); 

const — le32 *in = (const _ le32 *)src; 

. le32 *out = (. le32 *)dst; 


y = le32 to cpu(in[0]); 
z = le32 to cpu(in[1]); 
KO = ctx->KEY[0]; 
k1 = ctx->KEY[1]; 
k2 = ctx->KEY[2]; 
k3 = ctx->KEY[3]; 


n = TEA ROUNDS; 


while (n-- > 0) { 
sum += TEA DELTA; 
y += ((z << 4) + k0) ^ (z + sum) ^ ((z >> 5) + kl); 
z += ((y << 4) + k2) ^ (y + sum) ^ ((y >> 5) + k3); 


} 
out[0] = cpu to le32(y); 
out[1] = cpu to le32(z); 


} 


Et voici maintenant le résultat de la compilation: 


Listing 11.4 : Linux Kernel 3.2.0.4 pour Itanium 2 (McKinley) 


0090 | tea encrypt: 
0090|08 80 80 41 00 21 adds r16 = 96, r32 // ptr to ctx->2 
y KEY[2] 


7Explicitly Parallel Instruction Computing 
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0096|80 CO 82 
S KEY[0] 
009C|00 00 04 
00A0|09 18 70 
S KEY[1] 
00A6|F0 20 88 
00AC|44 06 01 
S KEY[3] 
00B0|08 98 00 
00B6|00 01 00 
y contain 
00BC|00 08 CA 
S register 
00C0|05 70 00 
9E FF FF 
00CC|92 F3 CE 
00D0|08 00 00 
00D6|50 01 20 
00DC|FO 09 2A 
V is 32 
00E0|0A AO 00 
00E6|20 01 80 
00EC|00 00 04 
00FO | 
00FO0 | 
00F0|09 80 40 


22 


& =TEA DELTA 


00F6|DO 71 54 
y kO 
OOFC|A3 70 68 
0100|03 FO 40 
0106|B0 El 50 
010C|D3 F1 3C 
0110|0B C8 6C 
0116|F0 78 64 
011C|00 00 04 
0120|00 00 00 
0126|80 51 3C 
012C|F1 98 4C 
0130|0B B8 3C 
0136|A0 CO 48 
013C|00 00 04 
0140|0B 48 28 
0146|60 B9 24 
014C|00 00 04 
0150|11 00 00 
0156|E0 70 58 
015C|A0 FF FF 
0160|09 20 3C 
0166|00 00 00 
016C|20 08 AA 

y register 
0170|11 00 38 


26 


42 


20 


80 


20 


40 


20 
00 


00 
60 


20 
00 


20 
00 


00 
AO 


15 
00 


11 


adds r8 = 88, r32 
nop.i 0 

adds r3 = 92, r32 
ld4 r15 = [r34], 4 
adds r32 = 100, r32;; 
ld4 r19 = [r16] 

mov r16 = r0 


mov.i r2 = ar.lc 


ld4 r14 = [r34] 


movl r17 = OxFFFFFFFF9E3779B9; ; 


nop.m 0 
ld4 r21 = [r8] 


mov.i ar.lc = 31 


1d4 r20 = [r3];; 
ld4 r18 = [r32] 
nop.i 0 

loc F0: 
add r16 - r16, r17 


shladd r29 = r14, 4, 


extr.u r28 = r14, 5, 


add r30 - r16, r14 
add r27 = r28, r20;; 
xor r26 = r29, r30;; 
xor r25 = r27, r26;; 
add r15 = r15, r25 
nop.i 0;; 

nop.m 0 

extr.u r24 = r15, 5, 
shladd r11 = r15, 4, 
add r23 = r15, r16;; 
add r10 - r24, r18 
nop.i 0;; 

xor r9 = r10, r11;; 
xor r22 - r23, r9 
nop.i 0;; 

nop.m 0 

add r14 - r14, r22 
br.cloop.sptk.few loc F0;; 
st4 [r33] = r15, 4 
nop.m 0 

mov.i ar.lc = r2;; 
st4 [r33] = r14 


r21 


275; 


27 
r19 


// 


// 


// 
// 


// 
// 


// 
// 
// 


// 
// 


// 
// 


// 


// 


// 


// 


// 
// 


// 
// 
// 


ptr to ctx->2 


ptr to ctx-»7 


load z 
ptr to ctx-»7 


r19-k2 
rO always 7 


save lc 7 
load y 
TEA DELTA 


r21-k0 
TEA ROUNDS 2 


r20-k1 
r18=k3 


rl6=sum, r177 
rl4=y, r21-7 


r20=k1 


r15=z 


r19=k2 


r18=k3 


store Z 
restore lc 7 


store y 
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0176|00 00 00 02 00 80 nop.i 0 
017C|08 00 84 00 br.ret.sptk.many b0;; 


Nous constatons tout d'abord que toutes les instructions IA64 sont regroupées par 
3. 


Chaque groupe représente 16 octets (128 bits) et se décompose en une catégorie 
de code sur 5 bits puis 3 instructions de 41 bits chacune. 


Dans IDA les groupes apparaissent sous la forme 6+6+4 octets —le motif est facile- 
ment reconnaissable. 


En règle générale les trois instructions d'un groupe s'exécutent en parallèle, sauf si 
l'une d'elles est associée à un «stop bit ». 


Il est probable que les ingénieurs d'Intel et de HP ont collecté des statistiques qui 
leur ont permis d'identifier les motifs les plus fréquents. lls auraient alors décidé 
d'introduire une notion de type de groupe (AKA «templates »). Le type du groupe 
définit la catégorie des instructions qu'il contient. Ces catégories sont au nombre de 
12. 


Par exemple, un groupe de type O représente MII. Ceci signifie que la premiére 
instruction est une lecture ou écriture en mémoire (M), la seconde et la troisiéme 
sont des manipulations d'entiers (I). 


Un autre exemple est le groupe de type Ox1d: MFB. La première instruction est la 
aussi de type mémoire (M), la seconde manipule un nombre flottant (F instruction 
FPU), et la derniére est un branchement (B). 


Lorsque le compilateur ne parvient pas à sélectionner une instruction à inclure dans 
le groupe en cours de construction, il utilise une instruction de type NOP. Il existe 
donc des instructions nop.i pour remplacer ce qui devrait étre une manipulation 
d'entier. De méme un nop.m est utilisé pour combler un trou là oú une instruction 
de type mémoire devrait se trouver. 


Lorsque le programme est directement rédigé en assembleur, les instructions NOPs 
sont ajoutées de maniére automatique. 


Et ce n'est pas tout. Les groupes font eux-mémes l'objet de regroupements. 


Chaque instruction peut étre marquée avec un «stop bit». Le processeur exécute en 
paralléle toutes les instructions, jusqu'à ce qu'il rencontre un «stop bit ». 


En pratique, les processeurs Itanium 2 peuvent exécuter jusqu'à deux groupes si- 
multanément, soit un total de 6 instructions en paralléle. 


Il faut évidemment que les instructions exécutées en paralléle, n'aient pas d'effet 
de bord entre elles. Dans le cas contraire, le résultat n'est pas défini. Le compilateur 
doit respecter cette contrainte ainsi que le nombre maximum de groupes simultanés 
du processeur cible en placant les «stop bit» au bon endroit. 


En langage d'assemblage, les bits d'arrét sont identifiés par deux point-virgule situés 
après l'instruction. 


Ainsi dans notre exemple les instructions [90-ac] peuvent étre exécutées simultané- 
ment. Le prochain groupe est [bO-cc]. 
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Nous observons également un bit d'arrét en 10c. L'instruction suivante comporte 
elle aussi un bit d'arrét. 


Ces deux instructions doivent donc étre exécutées isolément des autres, (comme 
dans une architecture CISC). 


En effet, l'instruction en 110 utilise le résultat produit par l'instruction précédente 
(valeur du registre r26). Les deux instructions ne peuvent s'exécuter simultanément. 


Il semble que le compilateur n'ai pas trouvé de meilleure maniére de paralléliser 
les instructions, ou en d'autres termes, de plus charger la CPU. Les bits d'arrét sont 
donc en trop grand nombre. 


La rédaction manuelle de code en assembleur est une táche pénible. Le program- 
meur doit effectuer lui-méme les regroupements d'instructions. 


Bien súr, il peut ajouter un bit d'arrét à chaque instruction mais cela dégrade les 
performances telles qu'elles ont été pensée pour l'Itanium. 


Les codes source du noyau Linux contiennent un exemple intéressant d'un code 
assembleur produit manuellement pour lA64 : 


http://lxr.free-electrons.com/source/arch/ia64/Llib/. 


On trouvera une introduction à l'assembleur Itanium dans : [Mike Burrell, Writing 
Efficient Itanium 2 Assembly Code (2010)]5, [papasutra of haquebright, WRITING 
SHELLCODE FOR IA-64 (2001)]?. 


Deux autres caractéristiques trés intéressantes d'Itanium sont l'exécution spécula- 
tive et le bit NaT («not a thing ») qui ressemble un peu aux nombres NaN : 
MSDN. 


11.7 Modele de mémoire du 8086 


Lorsque l'on a à faire avec des programmes 16-bit pour MS-DOS ou Win16 (8.8.3 
on page 1105 ou 3.34.5 on page 846), nous voyons que les pointeurs consistent en 
deux valeurs 16-bit. Que signifient-elles? Eh oui, c'est encore un artefact étrange de 
MS-DOS et du 8086. 


Le 8086/8088 était un CPU 16-bit, mais était capable d'accéder à des adresses mé- 
moire sur 20-bit (il était donc capable d'accéder 1MB de mémoire externe). 


L'espace de la mémoire externe était divisé entre la RAM (max 640KB), la ROM, la 
fenétre pour la mémoire vidéo, les cartes EMS, etc. 


Rappelons que le 8086/8088 était en fait un descendant du CPU 8-bit 8080. 
Le 8080 avait un espace mémoire de 16-bit, i.e., il pouvait seulement adresser 64KB. 


Et probablement pour une raison de portage de vieux logiciels!?, le 8086 peut sup- 
porter plusieurs fenétres de 64KB simultanément, situées dans l'espace d'adresse 
de 1MB. 


BAussi disponible en http: //yurichev.com/mirrors/RE/itanium.pdf 
Aussi disponible en http: //phrack.org/issues/57/5.html 
10Je ne suis pas sûr à 100% de ceci 
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C'est une sorte de virtualisation de niveau jouet. 


Tous les registres 8086 sont 16-bit, donc pour adresser plus, des registres spéciaux 
de segment (CS, DS, ES, SS) ont été ajoutés. 


Chaque pointeur de 20-bit est calculé en utilisant les valeurs d'une paire de registres, 
de segment et d'adresse (p.e. DS:BX) comme suit: 


real address = (segment register << 4) + address register 


Par exemple, la fenêtre de RAM graphique (EGA!!, VGA??) sur les vieux compatibles 
IBM-PC a une taille de 64KB. 


Pour y accéder, une valeur de 0xAO000 doit être stockée dans l'un des registres de 
segments, p.e. dans DS. 


Ainsi DS:0 adresse le premier octet de la RAM vidéo et DS:OxFFFF — le dernier octet 
de RAM. 


L'adresse réelle sur le bus d'adresse de 20-bit, toutefois, sera dans l'intervalle OxA0000 
à OxAFFFF. 


Le programme peut contenir des adresses codées en dur comme 0x1234, mais l'OS 
peut avoir besoin de le charger à une adresse arbitraire, donc il recalcule les valeurs 
du registre de segment de façon à ce que le programme n'ait pas à se soucier de 
l'endroit oü il est placé dans la RAM. 


Donc, tout pointeur dans le vieil environnement MS-DOS consistait en fait en un seg- 
ment d'adresse et une adresse dans ce segment, i.e., deux valeurs 16-bit. 20-bit 
étaient suffisants pour cela, cependant nous devions recalculer les adresses trés 
Souvent: passer plus d'informations par la pile semblait un meilleur rapport espace/- 
facilité. 

À propos, à cause de tout cela, il n'était pas possible d'allouer un bloc de mémoire 
plus large que 64KB. 


Les registres de segment furent réutilisés sur les 80286 comme sélecteurs, servant 
a une fonction différente. 


Lorsque les CPU 80386 et les ordinateurs avec plus de RAM ont été introduits, MS- 
DOS était encore populaire, donc des extensions pour DOS ont émergés: ils étaient 
en fait une étape vers un OS «sérieux », basculant le CPU en mode protégé et fournis- 
sant des APIs mémoire bien meilleures pour les programmes qui devaient toujours 
fonctionner sous MS-DOS. 


Des examples trés populaires incluent DOS/4GW (le jeux vidéo DOOM a été compilé 
pour lui), Phar Lap, PMODE. 


À propos, la méme maniére d'adresser la mémoire était utilisée dans la série 16-bit 
de Windows 3.x, avant Win32. 


Enhanced Graphics Adapter 
12Video Graphics Array 
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11.8 Réordonnancement des blocs élémentaires 


11.8.1 Optimisation guidée par profil 
Cette méthode d'optimisation déplace certains basic blocks vers d'autres sections 
du fichier binaire exécutable. 


Il est évident que certaines parties d'une fonction sont exécutées plus fréquemment 
que d'autres (ex: le corps d'une boucle) et d'autres moins souvent (ex: gestionnaire 
d'erreur, gestionnaires d'exception). 


Le compilateur ajoute dans le code exécutable des instructions d'instrumentation. 
Le développeur exécute ensuite un nombre important de tests, ce qui permet de 
collecter des statistiques. 


A l'aider de ces derniéres, le compilateur prépare le fichier exécutable final en dé- 
placant les fragments de code les moins exécutés vers une autre section. 


Tous les fragments de code les plus souvent exécutés sont ainsi regroupés, ce qui 
constitue un facteur important pour la rapidité d'exécution et l'utilisation du cache. 


Voici un exemple de code Oracle RDBMS produit par le compilateur Intel C++: 


Listing 11.5 : orageneric11.dll (win32) 


public skgfsync 
_skgfsync proc near 


; address 0x6030D86A 


db 66h 

nop 

push ebp 

mov ebp, esp 

mov edx, [ebp+0Ch] 

test edx, edx 

jz short loc 6030D884 

mov eax, [edx+30h] 

test eax, 400h 

jnz . VInfreq skgfsync ; write to log 
continue: 

mov eax, [ebp+8] 

mov edx, [ebp+10h] 

mov dword ptr [eax], 0 

lea eax, [edx+0Fh] 

and eax, OFFFFFFFCh 

mov ecx, [eax] 

cmp ecx, 45726963h 

jnz error ; exit with error 

mov esp, ebp 

pop ebp 

retn 


_skgfsync endp 
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; address 0x60B953F0 


__VInfreq__ skgfsync: 


mov eax, [edx] 
test eax, eax 

jz continue 

mov ecx, [ebp+10h] 
push ecx 

mov ecx, [ebp+8] 
push edx 

push ecx 


push offset ... ; 
"skgfsync(se=0x%x, ctx=0x%x, iov=0x%x)\n" 
push dword ptr [edx+4] 


call dword ptr [eax] ; write to log 
add esp, 14h 
jmp continue 
error: 
mov edx, [ebp+8] 
mov dword ptr [edx], 69AAh ; 27050 "function called with 
invalid FIB/IOV structure" 
mov eax, [eax] 
mov [edx+4], eax 
mov dword ptr [edx+8], OFA4h ; 4004 
mov esp, ebp 
pop ebp 
retn 


; END OF FUNCTION CHUNK FOR _skgfsync 


La distance entre ces deux fragments de code avoisine les 9 Mo. 


Tous les fragments de code rarement exécutés sont regroupés à la fin de la section 
de code de la DLL. 


La partie de la fonction qui a été déplacée était marquée par le compilateur Intel 
C++ avec le préfixe VInfreq. 


Nous voyons donc qu'une partie de la fonction qui écrit dans un fichier journal (pro- 
bablement à la suite d'une erreur ou d'un avertissement) n'a sans doute pas été 
exécuté trés souvent durant les tests effectués par les développeurs Oracle lors de 
la collecte des statistiques. Il n'est méme pas dit qu'elle ait jamais été exécutée. 


Le bloc élémentaire qui écrit dans le journal s'achéve par un retour à la partie «hot » 
de la fonction. 


Un autre bloc élémentaire «infrequent » est celui qui retourne le code erreur 27050. 


Pour ce qui est des fichiers Linux au format ELF, le compilateur Intel C++ déplace 
tous les fragments de code rarement exécutés vers une section séparée nommée 
text.unlikely. Les fragments les plus souvent exécutés sont quant à eux regrou- 
pés dans la section text .hot. 


Cette information peut aider le rétro ingénieur à distinguer la partie principale d'une 
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fonction des parties qui assurent la gestion d'erreurs. 


11.9 Mon expérience avec Hex-Rays 2.2.0 


11.9.1 Bugs 


Il y a plusieurs bugs. 


Tout d'abord, Hex-Rays est perdu lorsque des instructions FPU sont mélangées (par 
le générateur de code du compilateur) avec des autres. 


Par exemple, ceci: 


f proc near 
lea eax, [esp+4] 
fild dword ptr [eax] 
lea eax, [esp+8] 
fild dword ptr [eax] 
fabs 
fcompp 


fnstsw ax 
test ah, 1 


jz 101 
mov eax, 1 
retn 

101: 
mov eax, 2 
retn 

f endp 


...Sera correctement décompilé en: 


signed int cdecl f(signed int al, signed int a2) 


{ 


signed int result; // eax@2 


if ( fabs((double)a2) >= (double)al ) 


result = 2; 
else 
result = 1; 


return result; 


} 


Mais commentons une des instructions à la fin: 


101: 
;mov eax, 2 
retn 
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...Dous obtenons ce bug évident: 


void cdecl f(char al, char a2) 


fabs((double)a2); 
} 


Ceci est un autre bug: 


extrn f1:dword 
extrn f2:dword 


f proc near 
fld dword ptr [esp+4] 
fadd dword ptr [esp+8] 
fst dword ptr [esp+12] 
fcomp ds:const_100 
fld dword ptr [esp+16] ; commenter cette 7 


& instruction et ca sera OK 
fnstsw ax 
test ah, 1 


jnz short 101 
call f1 
retn 
101: 
call f2 
retn 
f endp 
const_100 dd 42C80000h ; 100.0 
Résultat: 


int _ cdecl f(float al, float a2, float a3, float a4) 
1 
double v5; // st7@l 
char v6; // c0Q1 
int result; // eax@2 


v5 = a4; 
if ( v6 ) 

result = f2(v5); 
else 

result = f1(v5); 
return result; 
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La variable v6 a un type char et si vous essayez de compiler ce code, le compilateur 
vous avertira à propos de l'utilisation de variable avant son initialisation. 


Un autre bug: l'instruction FPATAN est correctement décompilée en atan2(), mais 
les arguments sont échangés. 


11.9.2 Particularités bizarres 


Hex-Rays converti trop souvent des int 32-bit en 64-bit. Voici un exemple: 


f proc near 
mov eax, [esp+4] 
cdq 
xor eax, edx 
sub eax, edx 


; EAX-abs (al) 


sub eax, [esp+8] 
; EAX-EAX-a2 


; EAX à ce point est converti en 64-bit (RAX) 


cdq 
xor eax, edx 
sub eax, edx 


; EAX=abs (abs (al) -a2) 
retn 


f endp 


Résultat: 


int  cdecl f(int al, int a2) 
. int64 v2; // rax@l 
v2 = abs(al) - a2; 


return (HIDWORD(v2) ^ v2) - HIDWORD(v2) ; 
} 


Peut-être est-ce le résultat de l'instruction CDQ? Je ne suis pas sûr. Quoiqu'il en soit, 
à chaque fois que vous voyez le type  int64 dans du code 32-bit, soyez attentif. 


Ceci est aussi bizarre: 


f proc near 
mov esi, [esp+4] 
lea ebx, [esi+10h] 
cmp esi, ebx 


jge short 100 
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cmp esi, 1000 
jg short 100 
mov eax, 2 
retn 
100: 
mov eax, 1 
retn 
f endp 
Résultat: 
signed int _ cdecl f(signed int al) 
1 
signed int result; // eax@3 
if ( | OFSUB (al, al + 16) ^ 1 48 al <= 1000 ) 
result - 2; 
else 
result = 1; 
return result; 
} 


Le code est correct, mais il requiert une intervention manuelle. 


Parfois, Hex-Rays ne remplace pas le code de la division par la multiplication: 


f proc near 
mov eax, [esp+4] 
mov edx, 2AAAAAABh 
imul edx 
mov eax, edx 
retn 

f endp 

Résultat: 

int  cdecl f(int a1) 

1 

return (unsigned — int64)(715827883i164 * al) >> 32; 
} 


Ceci peut être remplacé manuellement. 


Beaucoup de ces particularités peuvent être résolues en ré-arrangeant les instruc- 
tions, recompilant le code assembleur et en le renvoyant dans Hex-Rays. 
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11.9.3 Silence 


extrn some_func:dword 


f proc near 
mov ecx, [esp+4] 
mov eax, [esp+8] 
push eax 
call some func 
add esp, 4 
; use ECX 
mov eax, ecx 
retn 

f endp 

Résultat: 


int  cdecl f(int al, int a2) 
int v2; // ecx@l 
some func(a2); 


return v2; 


} 


La variable v2 (de ECX) est perdue ...Oui, ce code est incorrect (la valeur de ECX 
n'est pas sauvée lors de l'appel d'une autre fonction), mais il serait bon que Hex- 
Rays donne un warning. 


Un autre: 


extrn some_func:dword 


f proc near 
call some func 
jnz 101 
mov eax, 1 
retn 

101: 
mov eax, 2 
retn 

f endp 

Résultat: 


signed int f() 
i 
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char v0; // zf@l 
signed int result; // eax@2 


some func(); 


if ( v0 ) 
result = 1; 
else 
result = 2; 


return result; 


Encore une fois, un warning serait utile. 


En tout cas, à chaque fois que vous voyez une variable de type char, ou une variable 
qui est utilisée sans initialisation, c'est un signe clair que quelque chose s'est mal 
passé et nécessite une intervention manuelle. 


11.9.4 Virgule 


La virgule en C/C++ a mauvaise presse, car elle peut conduire à du code confus. 


Quiz rapide, que renvoie cette fonction C/C++? 


int f() 
{ 


}; 


return 1, 2; 


C'est 2: lorsque le compilateur rencontre une expression avec des virgules, il génère 
du code qui exécute toutes les sous-expressions, et renvoie la valeur de la dernière. 


J'ai vu quelque chose comme ça dans du code en production: 


if (cond) 

return global var-123, 456; // 456 is returned 
else 

return global var-789, 321; // 321 is returned 


Il semble que le programmeur voulait rendre le code plus court sans parenthéses 
supplémentaires. Autrement dit, la virgule permet de grouper plusieurs expressions 
en une seule, sans déclaration/bloc de code dans des parenthéses. 


La virgule en C/C++ est proche du begin en Scheme/Racket: https://docs.racket- lang. 
org/guide/begin.html. 


Peut-étre que le seul usage largement accepté de la virgule est dans les déclarations 
for(): 


char *s="hello, world"; 
for(int i20; *s; s++, i++); 
; i = string lenght 


A la fois s++ et i++ sont exécutés à chaque itération de la boucle. 
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Plus d'information: 
http://stackoverflow.com/questions/52550/what-does-the-comma-operator-do-in-c. 


J'ai écrit tout ceci car Hex-Rays produit (au moins dans mon cas) du code qui est 
riche tant en virgules qu'en expression raccourcies: Par exemple, ceci est une sortie 
réelle de Hex-Rays: 


if (a >=b || (c =a, (d[al - e) >> 2 > f) ) 
1 


Ceci est correct, compile et fonctionne, et Dieu puisse vous aider à la comprendre. 
La voici récrite: 


if (cond1 || (comma expr, cond2)) 


{ 


Le raccourci est effectif ici: d'abord cond1 est testé, si c'est true, le corps du if() 
est exécuté, le reste de l'expression du if() est complétement ignoré. Si cond1 est 
false, comma expr est exécuté (dans l'exemple précédent, a est copié dans c), puis 
cond2 est testée. Si cond2 est true, le corps du if() est exécuté, ou pas. Autrement 
dit, le corps du if() est exécuté si cond1 est true ou si cond2 est true, mais si ce 
dernier est true, comma expr est aussi exécutée. 


Maintenant, vous pouvez voir pourquoi la virgule est si célébre. 


Un mot sur les raccourcis. Une idée fausse répandue de débutant est que les 
sous-conditions sont testées dans un ordre indéterminé, ce qui n'est pas vrai. Dans 
l'expressiona | b | c, a, bet csont évalués dans un ordre indéterminé, donc c'est 
pourquoi | | a été ajouté à C/C++, pour appliquer des raccourcis explicitement. 


11.9.5 Types de donnée 


Les types de donnée sont un probléme pour les décompilateurs. 


Hex-Rays peut ne pas voir les tableaux dans la pile locale, si ils n'ont pas été déter- 
minés avant la décompilation. Méme histoire avec les tableaux globaux. 


Un autre probléme se pose avec les fonctions trop grosses, oü un slot unique dans la 
pile locale peut étre utilisé par plusieurs variables durant l'exécution de la fonction. 
Ce n'est pas un cas rare que lorsqu'un slot est utilisé pour une variable int, puis un 
pointeur, puis une variable float. Hex-Rays le décompile correctement: il créé une 
variable avec le méme type, puis la caste sur un autre type dans diverses parties de 
la fonction. J'ai résolu ce probléme en découpant les grosses fonctions en plusieurs 
plus petites. Met les variables locales comme des globales, etc., etc. Et n'oubliez pas 
les tests. 


11.9.6 Expressions longues et confuses 


Parfois, lors de la ré-écriture, vous pouvez vous retrouvez avec des expressions 
longues et difficiles à comprendre dans des constructions if() comme: 
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if ((! (v38 && v30 <= 5 && v27 != -1)) && ((! (v38 66 v30 <= 5) && v27 != 7 


(! ( 
V -1) || (v24 >= 5 || v26)) && v25) 


Wolfram Mathematica peut minimiser certaines d'entre elles, en utilisant la fonction 
BooleanMinimize[] : 


In[1]:= BooleanMinimize[(! (v38 && v30 <= 5 && v27 != -1)) && v38 && v30 «-7 
& 5 && v25 == 0] 


Out[1]:= v38 && v25 == 0 && v27 == -1 && v30 <= 5 


Il y a encore une meilleure voie, pour trouver les sous-expressions communes: 


In[2]:= Experimental OptimizeExpression[(! (v38 && v30 <= 5 && 
v27 !- -1)) 88 ((! (v38 && v30 <= 5) & 
v27 !- -1) || (v24 >= 5 || v26)) 68 v25] 


Out[2]= Experimental OptimizedExpression[ 
Block[{Compile' $1, Compile'$2), Compile'$1 = v30 <= 5; 
Compile $2 = 
v27 !- -1; ! (v38 && Compile $1 && 
Compile'$2) && ((! (v38 && Compile' $1) && Compile' $2) || 
v24 >= 5 || v26) && v25]] 


Mathematica ajoute deux nouvelles variables: Compile'$1 et Compile’ $2, qui vont 
étre ré-utilisées plusieurs fois dans l'expression. Donc, nous pouvons ajouter deux 
variables supplémentaires. 


11.9.7 Loi de De Morgan et décompilation 


Parfois l'optimiseur du compilateur peut utiliser la loi de De Morgan pour rendre le 
code plus court/rapide. 


Par exemple, ceci: 


void f(int a, int b, int c, int d) 


1 
if (a>0 && b>0) 
printf ("both a and b are positive\n"); 
else if (c>0 && d>0) 
printf ("both c and d are positive\n"); 
else 
printf ("something else\n"); 
}; 


...ca semble assez anodin, lorsque c'est compilé avec GCC 5.4.0 x64 avec optimisa- 
tion: 
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; int fastcall f(int a, int b, int c, int d) 


public f 
f proc near 
test edi, edi 
jte short loc 8 
test esi, esi 
jg short loc 30 
loc 8: 
test edx, edx 
jte short loc 20 
test ecx, ecx 
jte short loc 20 
mov edi, offset s ; "both c and d are positive" 
jmp puts 
loc 20: 
mov edi, offset aSomethingElse ; "something else" 
jmp puts 
loc 30: 
mov edi, offset aAAndBPositive ; "both a and b are 
positive" 
loc 35: 
jmp puts 
f endp 


ça semble donc anodin, mais Hex-Rays 2.2.0 n'arrive pas vraiment à détecter 
qu'en fait des opérations double AND ont été utilisées dans le code source: 


int  fastcall f(int a, int b, int c, int d) 
int result; 


if (a»0&& b»0) 
1 


} 
else if ( c <= 0 || d <= 0 ) 


result = puts("both a and b are positive"); 


result = puts("something else"); 


} 
else 
{ 
result = puts("both c and d are positive"); 
} 
return result; 
} 
L'expression c <= 0 || d <= 0 est la contraposée de c>0 && d>0 puisque Au B = 


AnB et An B = AUB, Autrement dit, ! (cond1 || cond2) == !condl && !cond2 et 
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!(condl && cond2) == !cond1 || !cond2. 


Ca vaut la peine de garder ces régles à l'esprit, puisque ces optimisations du com- 
pilateur sont utilisées massivement presque partout. 


C'est parfois une bonne idée d'inverser une condition, afin de mieux comprendre le 
code. Ceci est un morceau de code réel décompilé par Hex-Rays: 


for (int i20; i<12; i++) 


1 
if (v1[i-12] != 0.0 || v1[i] != 0.0) 
1 
v108=min(v108, (float)vO[i*24 -2]); 
v113=max(v113, (float)v0[i*24]); 
Fi 
} 


...qui peut être récrit comme: 


for (int i=0; i<12; i++) 


{ 
if (v1[i-12] == 0.0 && v1[i] == 0.0) 
continue; 
v108=min(v108, (float)vO[i*24 -2]); 
v113=max(v113, (float)v0[i*24]); 
} 


Lequel est le meilleur? Je ne sais pas encore, mais pour une meilleure compréhension, 
c'est bien de regarder les deux. 


11.9.8 Mon plan 


* Séparer les grosses fonctions (et ne pas oublier de tester). Parfois c'est utile de 
créer des nouvelles fonctions à partir des corps de boucles. 


* Vérifier/tester le type des variables, tableaux, etc. 


* Si vous voyez un résultat étrange, une variable dangling (qui est utilisée avant 
son initialisation), essayez d'échanger les instructions manuellement, recompi- 
lez et repassez-le à Hex-Rays. 


11.9.9 Résumé 


Quoiqu'il en soit, la qualité de Hex-Rays 2.2.0 est trés, trés bonne. Il rend la vie plus 
facile. 


11.10 Complexité cyclomatique 


Ce terme est utilisé pour mesurer la complexité d'une fonction. Les fonctions com- 
plexes sont souvent un fléau, car elles sont difficiles à maintenir, difficiles à tester, 
etc. 
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Il y a plusieurs heuristiques pour la mesurer. 


Par exemple, on trouve dans la facon de coder du noyau Linux?? : 


Now, some people will claim that having 8-character indentations 
makes the code move too far to the right, and makes it hard to read on 
a 80-character terminal screen. The answer to that is that if you need 
more than 3 levels of indentation, you're screwed anyway, and should 
fix your program. 


Functions should be short and sweet, and do just one thing. They 
should fit on one or two screenfuls of text (the ISO/ANSI screen size is 
80x24, as we all know), and do one thing and do that well. 

The maximum length of a function is inversely proportional to the 
complexity and indentation level of that function. So, if you have a 
conceptually simple function that is just one long (but simple) case- 
statement, where you have to do lots of small things for a lot of dif- 
ferent cases, it's OK to have a longer function. 

However, if you have a complex function, and you suspect that a 
less-than-gifted first-year high-school student might not even unders- 
tand whatthe function is all about, you should adhere to the maximum 
limits all the more closely. Use helper functions with descriptive names 
(you can ask the compiler to in-line them if you think it's performance- 
critical, and it will probably do a better job of it than you would have 
done). 

Another measure of the function is the number of local variables. 
They shouldn't exceed 5-10, or you're doing something wrong. Re- 
think the function, and split it into smaller pieces. A human brain can 
generally easily keep track of about 7 different things, anything more 
and it gets confused. You know you're brilliant, but maybe you'd like 
to understand what you did 2 weeks from now. 


Dans le JPL Institutional Coding Standard for the C Programming Language" : 


Functions should be no longer than 60 lines of text and define no 
more than 6 parameters. 

A function should not be longer than what can be printed on a single 
sheet of paper in a standard reference format with one line per state- 
ment and one line per declaration. Typically, this means no more than 
about 60 lines of code per function. Long lists of function parameters 
similarly compromise code clarity and should be avoided. 

Each function should be a logical unit in the code that is unders- 
tandable and verifiable as a unit. It is much harder to understand a 
logical unit that spans multiple screens on a computer display or mul- 
tiple pages when printed. Excessively long functions are often a sign 


I3https://www.kernel.org/doc/html/v4.10/process/coding-style.html 
Mhttps://yurichev.com/mirrors/C/JPL Coding Standard C.pdf 
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of poorly structured code. 


Revenons maintenant à la complexité cyclomatique. 


Sans plonger profondément dans la théorie des graphes: il y a des blocs de base et 
des liens entre eux. Par exemple, voici comment IDA montre les BB?!°s et les liens 
(avec des fléches). En appuyant sur la barre d'espace, vous verrez ceci: 1.18 on 
page 122. Chaque BB est aussi appelé vertex ou noe dans la théorie des graphes. 
Chaque lien - aréte. 


Il y a au moins deux facons courantes de calculer la complexité cyclomatique: 1) 
arétes - noeds + 2 2) arétes - noeds + nombre de sorties (instructions RET) 


Dans l'exemple avec IDA ici-dessous, il y a 4 BBs, donc il y a 4 noeds. Mais il y aussi 
4 liens et une instruction de retour. 


Plus le nombre est grand, plus votre fonction est complexe et les choses vont de mal 
en pis. Comme vous pouvez le voir, une sortie supplémentaire (instruction return) 
rend les choses encore pire, tout comme des liens additionnels entre les noeds (un 
goto additionnel inclus). 


J'ai écris un simple script IDAPython (https://beginners.re/paywall/RE4B- source/ 
current-tree//other/cyclomatic/cyclomatic.py) pourla mesurer. Voici le résul- 
tat pour le noyau Linux 4.11 (ses fonctions les plus complexes) : 


1829c0 do check edges-937 nodes=574 rets-1 E-N+2=365 E-N+rets=364 

2effe0 ext4 fill super edges=862 nodes=568 rets=1 E-N+2=296 E-N+rets=295 

5d92e0 wm5110 readable register edges=661 nodes=369 rets=2 E-N+2=294 E-N+ 7 
y rets-294 

277650 do blockdev direct IO edges=771 nodes=507 rets=1 E-N+2=266 E-N+rets/ 
y =265 

10f7c0 load module edges=711 nodes=465 rets-1 E-N+2=248 E-N+rets=247 

787730 dev_ethtool edges=559 nodes=315 rets=1 E-N+2=246 E-N+rets=245 

84e440 do ipv6 setsockopt edges=468 nodes=237 rets=1 E-N+2=233 E-N+rets=232 

72c3c0 mmc init card edges=593 nodes=365 rets=1 E-N+2=230 E-N+rets=229 


( Liste complète: https: //beginners.re/paywall/RE4B-source/current-tree//other/ 
cyclomatic/linux 4.11 sorted.txt ) 


Voici le code source de certaines d'entre elles: do check(), ext4 fill super(), do blockdev direct IO(), 
do jit(). 


Fonctions les plus complexes du fichier ntoskrnl.exe de Windows 7: 


140569400 sub 140569400 edges=3070 nodes=1889 rets=1 E-N+2=1183 E-N+retsv 
y =1182 

14007c640 MmAccessFault edges=2256 nodes=1424 rets=1 E-N+2=834 E-N+rets=833 

140120410 FsRtlMdlReadCompleteDevEx edges=1241 nodes=752 rets=1 E-N+2=491 Ev 
V -N+rets=490 

14008c190 MmProbeAndLockPages edges=983 nodes=623 rets=1 E-N+2=362 E-N+retsv 
V =361 


15Basic Block 
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14037fd10 ExpQuerySystemInformation edges=995 nodes=671 rets=1 E-N+2=326 E- 7 
S N+rets=325 

140197260 MmProbeAndLockSelectedPages edges=875 nodes=551 rets=1 E-N+2=326 7 
V E-N+rets=325 

140362a50 NtSetInformationProcess edges=880 nodes=586 rets=1 E-N+2=296 E-N+2 
V rets=295 


( Liste complète: https: //beginners.re/paywall/RE4B-source/current-tree//other/ 
cyclomatic/win7 ntoskrnl sorted.txt ) 


Du point de vue du chasseur de bogues, les fonctions complexes sont plus suscep- 
tibles d'avoir des bogues, donc il faut leurs donner une attention particuliére. 


En lire plus à ce sujet: https://fr.wikipedia.org/wiki/Nombre cyclomatique, 
https://en.wikipedia.org/wiki/Cyclomatic complexity, http://wiki.c2.com/ 
?CyclomaticComplexityMetric 


Mesure de la complexité cyclomatique dans MSVS (CX) : https://blogs.msdn.microsoft. 
com/zainnab/2011/05/17/code-metrics-cyclomatic- complexity/. 


Une paire d'autres scripts Python pour mesurer la complexité dans IDA: http://www. 
openrce.org/articles/full view/11,https://github.com/mxmssh/IDAmetrics 
(incl. other metrics). 


Plugin GCC: https://github.com/ephox-gcc-plugins/cyclomatic complexity. 


Chapitre 12 


Livres/blogs qui valent le 
détour 


12.1 Livres et autres matériels 


12.1.1 Rétro-ingénierie 
* Eldad Eilam, Reversing: Secrets of Reverse Engineering, (2005) 


* Bruce Dang, Alexandre Gazet, Elias Bachaalany, Sebastien Josse, Practical Re- 
verse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Ob- 
fuscation, (2014) 


Michael Sikorski, Andrew Honig, Practical Malware Analysis: The Hands-On Guide 
to Dissecting Malicious Software, (2012) 


Chris Eagle, IDA Pro Book, (2011) 


Reginald Wong, Mastering Reverse Engineering: Re-engineer your ethical ha- 
cking skills, (2018) 


(Obsoléte, mais toujours intéressant) Pavol Cerven, Crackproof Your Software: Pro- 
tect Your Software Against Crackers, (2002). 


Également, les livres de Kris Kaspersky. 


12.1.2 Windows 


* Mark Russinovich, Microsoft Windows Internals 

* Peter Ferrie - The "Ultimate" Anti-Debugging Reference? 
Blogs: 

* Microsoft: Raymond Chen 


thttp://pferrie.host22.com/papers/antidebug. pdf 
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* nynaeve.net 


12.1.3 C/C++ 


* Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, 2ed, 
(1988) 


* ISO/IEC 9899:TC3 (C C99 standara), (2007)? 

* Bjarne Stroustrup, The C++ Programming Language, 4th Edition, (2013) 
* C++11 standard? 

* Agner Fog, Optimizing software in C++ (2015)^ 

* Marshall Cline, C++ FAQ? 


* Dennis Yurichev, C/C++ programming language notes 


JPL Institutional Coding Standard for the C Programming Language” 


12.1.4 Architecture x86 / x86-64 


* Manuels Intel? 

* Manuels AMD? 

* Agner Fog, The microarchitecture of Intel, AMD and VIA CPUs, (2016)? 

* Agner Fog, Calling conventions (2015)! 

Intel® 64 and IA-32 Architectures Optimization Reference Manual, (2014) 


* Software Optimization Guide for AMD Family 16h Processors, (2013) 
Quelque peu vieux, mais toujours intéressant à lire : 


Michael Abrash, Graphics Programming Black Book, 1997?? (il est connu pour son 
travail sur l'optimisation bas niveau pour des projets tels que Windows NT 3.1 et id 
Quake). 


2Aussi disponible en http: //www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf 

3Aussi disponible en http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690 pdf. 

^Aussi disponible en http://agner.org/optimize/optimizing cpp.pdf. 

5Aussi disponible en http://www. parashift.com/c++- faq-lite/index.html 

SAussi disponible en http: //yurichev.com/C-book.html 

Aussi disponible en https: //yurichev.com/mirrors/C/JPL_ Coding Standard C.pdf 

8Aussi disponible en http://www.intel.com/content/www/us/en/processors/ 
architectures-software-developer-manuals.html 

9Aussi disponible en http: //developer.amd.com/resources/developer-guides-manuals/ 

10Aussi disponible en http://agner.org/optimize/microarchitecture.pdf 

Aussi disponible en http://www.agner.org/optimize/calling conventions.pdf 

12Aussi disponible en https://github.com/jagregory/abrash-black- book 
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12.1.5 ARM 
* Manuels ARM? 
* ARM(R) Architecture Reference Manual, ARMv7-A and ARMv7-R edition, (2012) 


* [ARM Architecture Reference Manual, ARMv8, for ARMv8-A architecture profile, 
(2013)]4 


* Advanced RISC Machines Ltd, The ARM Cookbook, (1994)15 


12.1.6 Langage d'assemblage 


Richard Blum — Professional Assembly Language. 


12.1.7 Java 


[Tim Lindholm, Frank Yellin, Gilad Bracha, Alex Buckley, The Java(R) Virtual Machine 
Specification / Java SE 7 Edition] **. 


12.1.8 UNIX 
Eric S. Raymond, The Art of UNIX Programming, (2003) 


12.1.9 Programmation en général 


* Brian W. Kernighan, Rob Pike, Practice of Programming, (1999) 


* Henry S. Warren, Hacker's Delight, (2002)Certaines personnes disent que les 
trucs et astuces de ce livre ne sont plus pertinents aujourd'hui, car ils n'étaient 
valables que pour les CPUs RISC, ou les instructions de branchement sont coü- 
teuses. Néanmoins, ils peuvent énormément aider à comprendre l'algébre boo- 
léenne et toutes les mathématiques associées. 


12.1.10 Cryptographie 
* Bruce Schneier, Applied Cryptography, (John Wiley & Sons, 1994) 
e (Free) Ivh, Crypto 101*” 
e (Free) Dan Boneh, Victor Shoup, A Graduate Course in Applied Cryptography??. 


13Aussi disponible en http://infocenter.arm.com/help/index.jsp?topic-/com.arm.doc.subset. 
architecture.reference/index.html 

aussi disponible en http://yurichev.com/mirrors/ARMv8-A Architecture Reference Manual _ 
(Issue A.a).pdf 

15Aussi disponible en https: //yurichev.com/ref /ARM%20Cookbook%20 (1994) / 

16Aussi disponible en https: //docs.oracle.com/javase/specs/jvms/se7/jvms7 .pdf ; http://docs. 
oracle.com/javase/specs/jvms/se7/html/ 

17 Aussi disponible en https: //www.crypto101.io/ 

18Aussi disponible en https://crypto.stanford.edu/-dabo/cryptobook/ 


Chapitre 13 


Communautés 


Il existe deux excellents subreddits liés à la RE! (rétro-ingénierie) sur reddit.com : 
reddit.com/r/ReverseEngineering/ et reddit.com/r/remath (en lien avec la liaison de 
la RE et des mathématiques). 


Il y a également une section sur l'RE sur le site Stack Exchange: 
reverseengineering.stackexchange.com. 


Sur IRC, il y a les canaux ##re et ##asm sur Libera. 


lReverse Engineering 
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Épilogue 
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13.1 Des questions? 


Pour toute question, n'hésitez pas a m'envoyer un mail : 
my emails. Vous avez une suggestion ou une proposition de contenu supplémentaire 
pour le livre ? N'hésitez pas à envoyer toute correction (grammaire incluse), etc... 


Je travaille beaucoup sur cette œuvre, c'est pourquoi les numéros de pages et les 
numéros de parties peuvent changer rapidement. S'il vous plait, ne vous fiez pas à 
ces derniers si vous m'envoyez un email. Il existe une méthode plus simple : faites 
une capture d'écran de la page, puis dans un éditeur graphique, soulignez l'endroit 
ou il y a une erreur et envoyez-moi l'image. Je la corrigerai plus rapidement. Et si 
vous étes familier avec git et ATEX vous pouvez corriger l'erreur directement dans le 
code source : 


https://beginners.re/src/. 


N'hésitez surtout pas à m'envoyer la moindre erreur que vous pourriez trouver, aussi 
petite soit-elle, méme si vous n'étes pas certain que ce soit une erreur. J'écris pour 
les débutants aprés tout, il est donc crucial pour mon travail d'avoir les retours de 
débutants. 


Appendice 
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.1 x86 


.1.1 Terminologie 
Commun en 16-bit (8086/80286), 32-bit (80386, etc.), 64-bit. 


octet 8-bit. La directive d'assembleur DB est utilisée pour définir les variables et les 
tableaux d'octets. Les octets sont passés dans les parties 8-bit des registres: 
AL/BL/CL/DL/AH/BH/CH/DH/SIL/DIL/R*L. 


mot 16-bit. directive assembleur DW —"—. Les mots sont passés dans la partie 16- 
bit des registres: 
AX/ BX/ CX/DX/SI/DI/R*W. 


double mot («dword ») 32-bit. directive assembleur DD —”—. Les double mots sont 
passés dans les registres (x86) ou dans la partie 32-bit de registres (x64). Dans 
du code 16-bit, les double mots sont passés dans une paire de registres 16-bit. 


quadruple mot («qword») 64-bit. directive assembleur DQ —"—. En environne- 
ment 32-bit, les quadruple mots sont passés dans une paire de registres 32-bit. 


tbyte (10 bytes) 80-bit ou 10 octets (utilisé pour les registres FPU IEEE 754). 
paragraph (16 bytes)—le terme était répandu dans l'environnement MS-DOS. 


Des types de données de méme taille (BYTE, WORD, DWORD) existent aussi dans 
l'API Windows. 


.1.2 Registres à usage général 


Il est possible d'accéder à de nombreux registres par octet ou par mot de 16-bit. 
Les vieux CPUs 8-bit (8080) avaient des registres de 16-bit divisés en deux. 


Les programmes écrits pour 8080 pouvaient accéder à l'octet bas des registres de 
16-bit, à l'octet haut ou au registre 16-bit en entier. 


Peut-étre que cette caractéristique a été conservée dans le 8086 pour faciliter le 
portage. 


Cette caractéristiques n'est en général pas présente sur les CPUs RISC. 


Les registres préfixés par R- sont apparus en x86-64, et ceux préfixés par E- —dans 
le 80386. 


Ainsi, les R-registres sont 64-bit, et les E-registres—32-bit. 
8 GPR ont été ajoutés en x86-64: R8-R15. 


N.B.: Dans les manuels Intel, les parties octet de ces registres sont préfixées par , 
e.g.: , mais IDA nomme ces registres en ajoutant le suffixe , e.g.: . 
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RAX/EAX/AX/AL 


Octet d'indice 
716 54131211 0 
RAX* 


AH | AL 


AKA accumulateur Le résultat d'une fonction est en général renvoyé via ce registre. 


RBX/EBX/BX/BL 
Octet d'indice 
716 5413/1211 0 
RBX* 
EBX 
BX 
BH | BL 
RCX/ECX/CX/CL 


Octet d'indice 
716 5 4 3/|2|1 0 
RCX* 


CH | CL 


AKA compteur: il est utilisé dans ce róle avec les instructions préfixées par REP et 
aussi dans les instructions de décalage (SHL/SHR/RxL/RxR). 


RDX/EDX/DX/DL 


Octet d'indice 
716 5 44 3|2|1 0 
RDX* 


RSI/ESI/SI/SIL 


Octet d'indice 
716 5 4 3121110 
RSI* 


ESI 


S|L X64 
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AKA «source index ». Utilisé comme source dans les instructions REP MOVSx, REP 
CMPSx. 


RDI/EDI/DI/DIL 


Octet d'indice 
7116|5|4/3|2|1 0 
RDI*64 


EDI 


DI 
DIL*® | 


AKA «destination index ». Utilisé comme un pointeur sur la destination dans les ins- 
tructions REP MOVSx, REP STOSx. 


R8/R8D/R8W/R8L 
Octet d'indice 
716 5|4|3|2|1|0 
R8 
R8D 
R8W 
R8L 
R9/R9D/R9W/R9L 
Octet d'indice 
716 |5|4|3|2|1|0 
R9 
R9D 
ROW 
ROL 
R10/R10D/R10W/R10L 


Octet d'indice 
716 5|4|3|2|1/0 
R10 


R10D 
R10W 
R10L 
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R11/R11D/R11W/R11L 


R12/R12D/R12W/R12L 


R13/R13D/R13W/R13L 


R14/R14D/R14W/R14L 


R15/R15D/R15W/R15L 


Octet d'indice 


5 


4 


3 


R11 


Octet d'indice 


5 


4 


3 


2 


1 


R12 


R12D 


R12W 


R12L 


Octet d'indice 


5 


4 


3 


2 


1 


R13 


R13D 


R13W 


R13L 


Octet d'indice 


5 


4 


3 


2 


R14 


Octet d'indice 


5 


4 


3 


2 


1 


R15 


R15D 


R15W 


R15L 
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RSP/ESP/SP/SPL 


Octet d'indice 
716 | 5|4|3|2|1|0 
RSP 


ESP 


SP 
SPL 


AKA pointeur de pile. Pointe en général sur la pile courante excepté dans le cas ou 
il n'est pas encore initialisé. 


RBP/EBP/BP/BPL 


Octet d'indice 
716 5|4|3|2|1|0 
RBP 


EBP 


BP 
BPL 


AKA frame pointer. Utilisé d'habitude pour les variables locales et accéder aux argu- 
ments de la fonction. En lire plus ici: (1.12.1 on page 94). 


RIP/EIP/IP 


Octet d'indice 
7|6|5|]14/|31]2|11]|0 
RIP 


EIP 


IP 


AKA «instruction pointer » ?. En général, il pointe toujours sur l'instruction en cours 
d'exécution. Il ne peut pas étre modifié, toutefois, il est possible de faire ceci (ce qui 
est équivalent) : 


MOV EAX, 
JMP EAX 


Ou: 


PUSH value 
RET 


CS/DS/ES/SS/FS/GS 


Les registres 16-bit contiennent le sélecteur de code (CS), le sélecteur de données 
(DS), le sélecteur de pile (SS). 


2Parfois appelé «program counter » 
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FS dans win32 pointe sur TLS, GS prend ce róle dans Linux. C'est fait pour accé- 
der plus au TLS et autres structures comme le TIB. 
Dans le passé, ces registres étaient utilisés comme registres de segments (11.7 on 


page 1297). 


Registre de flags 


AKA EFLAGS. 


Bit (masque) 


Abréviation (signification) 


Description 


CF (Carry) 


Les instructions CLC/STC/CMC sont utilisées 
pour mettre/effacer/changer ce flag 


2 (4) PF (Parity) (1.25.7 on page 303). 
4 (0x10) AF (Adjust) Existe seulement pour travailler avec les nombres BCD 
6 (0x40) ZF (Zero) Mettre à 0 
si le résultat de la derniére opération est égal à O. 
7 (0x80) SF (Sign) 
8 (0x100) TF (Trap) Utilisé pour le débogage. 
S'il est mis, une exception est générée 
aprés l'exécution de chaque instruction. 
9 (0x200) IF (Interrupt enable) Est-ce que les interruptions sont activées 
Les instructions CLI/STI sont utilisées 
pour activer/désactiver le flag 
10 (0x400) DF (Direction) Une direction est défini pour les 
instructions REP MOVSx/CMPSx/LODSx/SCASx 
Les instructions CLD/STD sont utilisées 
pour activer/désactiver le flag 
Voir aussi 3.26 on page 812. 
11 (0x800) OF (Overflow) 


12, 13 (0x3000) 


IOPL (I/O privilege level)?9* 


14 (0x4000) 


NT (Nested task)?" 


16 (0x10000) 


RF (Resume) 556 


Utilisé pour le débogage. 
Le CPU ignore le point d'arrêt 
matériel dans DRx si le flag est mis. 


17 (0x20000) VM (Virtual 8086 mode)*** 

18 (0x40000) AC (Alignment check)"?5 

19 (0x80000) VIF (Virtual interrupt)^?5 

20 (0x100000) VIP (Virtual interrupt pending)*** 
21 (0x200000) ID (Identification)'?8e 


Tous les autres flags sont réservés. 


.1.3 Registres FPU 


8 registres de 80-bit fonctionnant comme une pile: ST(0)-ST(7). N.B.: IDA nomme 
ST(0) simplement en ST. Les nombres sont stockés au format IEEE 754. 


Format d'une valeur : 


79 78 


64 63 62 
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exposant l 


mantisse ou fraction 


( S — signe, | — partie entière ) 


Mot de Contrôle 


Registre contrôlant le comportement du FPU. 


Bit Abréviation (signification) Description 
0 IM (Invalid operation Mask) 
1 DM (Denormalized operand Mask) 
2 ZM (Zero divide Mask) 
3 OM (Overflow Mask) 
4 UM (Underflow Mask) 
5 PM (Precision Mask) 
7 IEM (Interrupt Enable Mask) Exceptions activées, 1 par défaut (désactivées) 
8,9 PC (Precision Control) 
00 — 24 bits (REAL4) 
10 — 53 bits (REAL8) 
11 — 64 bits (REAL10) 
10, 11 | RC (Rounding Control) 
00 — (par défaut) arrondir au plus proche 
01 — arrondir vers —oo 
10 — arrondir vers +00 
11 — arrondir vers O 
12 IC (Infinity Control) O — (par défaut) traite +00 et - comme non signé 


1 — respecte à la fois +00 et -oo 


Les flags PM, UM, OM, ZM, DM, IM définissent si une exception est générée en cas 
d'erreur correspondante. 


Mot d'état 


Registre en lecture seule. 


Bit Abréviation (signification) | Description 

15 B (Busy) Est-ce que le FPU fait quelque chose (1) 
ou des résultats sont préts (0) 

14 C3 

13, 12, 11 | TOP pointe sur le registre zéro actuel 

10 C2 

9 C1 

8 CO 

7 IR (Interrupt Request) 

6 SF (Stack Fault) 

5 P (Precision) 

4 U (Underflow) 

3 O (Overflow) 

2 Z (Zero) 

1 D (Denormalized) 

0 | (Invalid operation) 
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Les bits SF, P, U, O, Z, D, | indiquent les exceptions. 
Vous trouverez des précisions a propos de C3, C2, C1, CO ici: (1.25.7 on page 303). 
N.B.: Lorsque ST(x) est utilisé, le FPU ajoute z à TOP (modulo 8) et c'est ainsi qu'il 


obtient le numéro du registre interne. 
Mot Tag 


Le registre possède l'information actuelle à propos de l'utilisation des registres de 
nombres. 


Bit Abréviation (signification) 
15, 14 | Tag(7) 
13, 12 | Tag(6) 
11, 10 | Tag(5) 
9,8 Tag(4) 
7,6 Tag(3) 
5,4 Tag(2) 
3,2 Tag(1) 
1,0 Tag(0) 


Chaque tag contient l'information à propos d'un registre FPU physique, pas logique 
(ST(x)). 


Pour chaque tag: 
* 00 — Le registre contient une valeur non-zéro 
e 01 — Le registre contient 0 
e 10 — Le registre contient une valeur particulière (NAN?, œ, ou anormale) 


* 11 — Le registre est vide 


.1.4 Registres SIMD 
Registres MMX 
8 registres 64-bit: MMO..MM7. 


Registres SSE et AVX 


SSE: 8 registres 128-bit: XMMO..XMM7. En x86-64 8 autres registres ont été ajoutés: 
XMM8..XMM15. 


AVX est l'extension de tous ces registres à 256 bits. 


.1.5 Registres de débogage 


Ils sont utilisés pour le contrôle des points d'arrêt matériel (hardware breakpoints). 


3Not a Number 
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DRO — adresse du point d'arrét #1 
DR1 — adresse du point d'arrêt #2 
DR2 — adresse du point d'arrét #3 
DR3 — adresse du point d'arrét #4 


* DR6 — la cause de l'arrét est indiquée ici 


* DR7 — les types de point d'arrét sont mis ici 


DR6 


Bit (masque) 


Description 


0 (1) 


BO — le point d'arrét #1 a été déclenché 


1 (2) B1 — le point d'arrét #2 a été déclenché 
2 (4) B2 — le point d'arrét #3 a été déclenché 
3 (8) B3 — le point d'arrét #4 a été déclenché 


13 (0x2000) 


BD — tentative de modification d'un des registres DRx. 
peut étre déclenché si GD est activé 


14 (0x4000) 


BS — point d'arrét simple (le flag TF a été mis dans EFLAGS). 
La plus haute priorité. D'autres bits peuvent étre mis aussi. 


15 (0x8000) 


BT (task switch flag) 


N.B. Un point d'arrét simple est un point d'arrét qui se produit aprés chaque instruc- 
tion. Il peut étre enclenché en mettant le flag TF dans EFLAGS (.1.2 on page 1326). 


DR7 


Les types de point d'arrét sont mis ici. 


Bit (masque) Description 

0 (1) LO — activer le point d'arrét #1 pour la táche courante 

1 (2) GO — activer le point d'arrét +1 pour toutes les táches 

2 (4) L1 — activer le point d'arrét #2 pour la táche courante 

3 (8) G1 — activer le point d'arrét #2 pour toutes les taches 

4 (0x10) L2 — activer le point d'arrét #3 pour la táche courante 

5 (0x20) G2 — activer le point d'arrét +3 pour toutes les táches 

6 (0x40) L3 — activer le point d'arrét #4 pour la táche courante 

7 (0x80) G3 — activer le point d'arrét #4 pour toutes les taches 

8 (0x100) LE — non supporté depuis P6 

9 (0x200) GE — non supporté depuis P6 

13 (0x2000) GD — exception déclenchée si une instruction MOV 
essaye de modifier un des registres DRx 

16,17 (0x30000) point d'arrét #1: R/W — type 

18,19 (0xC0000) point d'arrét #1: LEN — longueur 

20,21 (0x300000) point d'arrét #2: R/W — type 

22,23 (0xC00000) point d'arrét 42: LEN — longueur 

24,25 (0x3000000) point d'arrét #3: R/W — type 

26,27 (0xC000000) point d'arrét #3: LEN — longueur 

28,29 (0x30000000) | point d'arrét 44: R/W — type 

30,31 (0xC0000000) | point d'arrét #4: LEN — longueur 
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Le type de point d'arrét doit étre mis comme suit (R/W) : 
* 00 — exécution de l'instruction 
* 01 — écriture de données 
e 10 — lecture ou écriture I/O (non disponible en mode user) 
e 11 — a la lecture ou l'écriture de données 


N.B.: le type de point d'arrét est absent pour la lecture de données, en effet. 


La longueur du point d'arrét est mise comme suit (LEN) : 
* 00 — un octet 
* 01 — deux octets 
* 10 — non défini pour le mode 32-bit, huit octets en mode 64-bit 


* 11 — quatre octets 


.1.6 Instructions 


Les instructions marquées avec un (M) ne sont généralement pas générées par le 
compilateur: si vous rencontrez l'une d'entre elles, il s'agit probablement de code 
assembleur écrit à la main, ou de fonctions intrinséques (11.4 on page 1290). 


Seules les instructions les plus fréquemment utilisées sont listées ici. Vous pouvez 
lire 12.1.4 on page 1315 pour une documentation complète. 


Devez-vous connaítre tous les opcodes des instructions par coeur? Non, seulement 
ceux qui sont utilisés pour patcher du code (11.2.1 on page 1288). Tout le reste des 
opcodes n'a pas besoin d'étre mémorisé. 


Préfixes 


LOCK force le CPU à faire un accés exclusif à la RAM dans un environnement multi- 
processeurs. Par simplification, on peut dire que lorsqu'une instruction avec ce 
préfixe est exécutée, tous les autres CPU dans un systéme multi-processeur 
sont stoppés. Le plus souvent, c'est utilisé pour les sections critiques, les séma- 
phores et les mutex. Couramment utilisé avec ADD, AND, BTR, BTS, CMPXCHG, 
OR, XADD, XOR. Vous pouvez en lire plus sur les sections critiques ici (6.5.4 on 
page 1026). 


REP est utilisé avec les instructions MOVSx et STOSx: exécute l'instruction dans une 
boucle, le compteur est situé dans le registre CX/ECX/RCX. Pour une description 
plus détaillée de ces instructions, voir MOVSx (.1.6 on page 1334) et STOSx (.1.6 
on page 1336). 


Les instructions préfixées par REP sont sensibles au flag DF, qui est utilisé pour 
définir la direction. 
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REPE/REPNE (AKA REPZ/REPNZ) utilisé avec les instructions CMPSx et SCASx: exé- 

cute la derniére instruction dans une boucle, le compteur est mis dans le re- 

gistre CX/ECX/RCX. Elle s'arréte prématurément si ZF vaut O (REPE) ou si ZF 
vaut 1 (REPNE). 


Pour une description plus détaillée de ces instructions, voir CMPSx (.1.6 on 
page 1338) et SCASx (.1.6 on page 1335). 


Les instructions préfixées par REPE/REPNE sont sensibles au flag DF, qui est 
utilisé pour définir la direction. 


Instructions les plus fréquemment utilisées 


Celles-ci peuvent étre mémorisées en premier. 


ADC (add with carry) ajoute des valeurs, incrémente le résultat si le flag CF est mis. 
ADC est souvent utilisé pour ajouter des grandes valeurs, par exemple, pour 
ajouter deux valeurs 64-bit dans un environnement 32-bit en utilisant deux 
instructions, ADD et ADC. Par exemple: 


; fonctionne avec des valeurs 64-bit: ajoute vall à val2. 

; .lo signifie les plus bas des 32 bits, .hi signifie les plus hauts. 

ADD vall.lo, val2.lo 

ADC vall.hi, val2.hi ; utilise CF mis à 0 ou 1 par l'instruction 
précédente 


Un autre exemple: 1.34 on page 509. 
ADD ajoute deux valeurs 
AND «et» logique 


CALL appelle une autre fonction: 
PUSH address after CALL instruction; JMP label 


CMP compare les valeurs et met les flags, comme SUB mais sans écrire le résultat 


DEC décrémente. Contrairement aux autres instructions arithmétiques, DEC ne mo- 
difie pas le flag CF. 


IMUL multiplication signée IMUL est souvent utilisé à la place de MUL, voir ici: 11.1 
on page 1287. 


INC incrémente. Contrairement aux autres instructions arithmétiques, INC ne modi- 
fie pas le flag CF. 


JCXZ, JECXZ, JRCXZ (M) saute si CX/ECX/RCX=0 
JMP saute à une autre adresse. L'opcode a un jump offset. 
Jcc (où cc — condition code) 


Beaucoup de ces instructions ont des synonymes (notés avec AKA), qui ont été 
ajoutés par commodité. lls sont codés avec le méme opcode. L'opcode a un 
offset de saut. 


JAE AKA JNC: saut si supérieur ou égal (non signé) : C20 
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JA AKA JNBE: saut si supérieur (non signé) : CF=0 et ZF=0 
JBE saut si inférieur ou égal (non signé) : CF=1 ou ZF=1 
JB AKA JC: saut si inférieur(non signé) : CF=1 
JC AKA JB: saut si CF=1 
JE AKA JZ: saut si égal ou zéro: ZF=1 
JGE saut si supérieur ou égal (signé) : SFZOF 
JG saut si supérieur (signé) : ZF=0 et SF=OF 
JLE saut si inférieur ou égal (signé) : ZF=1 ou SF«OF 
JL saut si inférieur (signé) : SF+OF 
JNAE AKA JC: saut si non supérieur ou égal (non signé) : CF=1 
JNA saut si non supérieur (non signé) : CF=1 et ZF=1 
JNBE saut si non inférieur ou égal (non signé) : CF=0 et ZF=0 
JNB AKA JNC: saut si non inférieur (non signé) : CF=0 
JNC AKA JAE: saut si CF=0, synonyme de JNB. 
JNE AKA JNZ: saut si non égal ou non zéro: ZF=0 
JNGE saut si non supérieur ou égal (signé) : SF+OF 
JNG saut si non supérieur (signé) : ZF=1 ou SF+OF 
JNLE saut si non inférieur ou égal (signé) : ZF=0 et SF=OF 
JNL saut si non inférieur (signé) : SF=OF 
JNO saut si non débordement: OF=0 
JNS saut si le flag SF vaut zéro 
JNZ AKA JNE: saut si non égal ou non zéro: ZF=0 
JO saut si débordement: OF=1 
JPO saut si le flag PF vaut 0 (Jump Parity Odd) 
JP AKA JPE : saut si le flag PF est mis 
JS saut si le flag SF est mis 
JZ ^KA JE: saut si égal ou zéro: ZF=1 
LAHF copie certains bits du flag dans AH: 
7 


6 4 2 0 


SFZF AF PF ICH 


Cette instruction est souvent utilisée dans du code relatif au FPU. 


LEAVE équivalente à la paire d'instructions MOV ESP, EBP et POP EBP — autrement 
dit, cette instruction remet le pointeur de pile et restaure le registre EBP à l'état 
initial. 
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LEA (Load Effective Address) forme une adresse 


Cette instruction n'a pas été concue pour sommer des valeurs et/ou les multi- 
plier, mais pour former une adresse, e.g., pour calculer l'adresse d'un élément 
d'un tableau en ajoutant l'adresse du tableau, l'index de l'élément multiplié par 
la taille de l'élément^. 


Donc, la différence entre MOV et LEA est que MOV forme une adresse mémoire 
et charge une valeur depuis la mémoire ou l'y stocke, alors que LEA forme 
simplement une adresse. 


Mais néanmoins, elle peut étre utilisée pour tout autre calcul. 


LEA est pratique car le calcul qu'elle effectue n'altére pas les flags du CPU. 
Ceci peut étre trés important pour les processeurs OOE (afin de créer moins 
de dépendances). À part ca, au moins à partir du Pentium, l'instruction LEA est 
exécutée en 1 cycle. 


int f(int a, int b) 
1 
return a*8+b; 
un 
Listing 1: MSVC 2010 avec optimisation 
_a$ = 8 ; size = 4 
_b$ = 12 ; size = 4 
f PROC 
mov eax, DWORD PTR _b$[esp-4] 
mov ecx, DWORD PTR _a$[esp-4] 
lea eax, DWORD PTR [eax+ecx*8] 
ret 0 
f ENDP 
Intel C++ utilise encore plus LEA: 
int fl(int a) 
{ 
return a*13; 
un 
Listing 2 : Intel C++ 2011 
_ fl PROC NEAR 
mov ecx, DWORD PTR [4+esp] ; ecx =a 
lea edx, DWORD PTR [ecx+ecx*8] ; edx = a*9 
lea eax, DWORD PTR [edx+ecx*4] ; eax = a*9 + a*4 = a*13 
ret 


Ces deux instructions sont plus rapide qu’un IMUL. 


4Voir aussi: Wikipédia 
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MOVSB/MOVSW/MOVSD/MOVSQ copier l'octet/ le mot 16-bit/ le mot 32-bit/ le 
mot 64-bit depuis l'adresse se trouvant dans SI/ESI/RSI vers celle se trouvant 
dans DI/EDI/RDI. 


Avec le préfixe REP, elle est répétée en boucle, le compteur étant stocker dans 
le registre CX/ECX/RCX: ca fonctionne comme memcpy() en C. Si la taille du 
bloc est connue pendant la compilation, memcpy() est souvent mise en ligne 
dans un petit morceau de code en utilisant REP MOVSx, parfois méme avec 
plusieurs instructions. 


L'équivalent de memcpy(EDI, ESI, 15) est: 


; copier 15 octets de ESI vers EDI 

CLD ; mettre la direction à en avant 
MOV ECX, 3 

REP MOVSD ; copier 12 octets 

MOVSW ; copier 2 octets de plus 

MOVSB ; copier l'octet restant 


(Apparemment, c'est plus rapide que de copier 15 octets avec un seul REP 
MOVSB). 


MOVSX charger avec extension du signe voir aussi: (1.23.1 on page 264) 
MOVZX icharger et effacer tous les autres bits voir aussi: (1.23.1 on page 265) 


MOV charger une valeur. Le nom de cette instruction est inapproprié, ce qui en- 
traine des confusions (la donnée n'est pas déplacée, mais copiée), dans d'autres 
architectures la méme instruction est en général appelée «LOAD » et/ou «STORE » 
ou quelque chose comme ca. 


Une chose importante: si vous mettez la partie 16-bit basse d'un registre 32-bit 
en mode 32-bit, les 16-bit haut restent comme ils étaient. Mais si vous modifiez 
la partie 32-bit basse d'un registre en mode 64-bit, les 32-bits haut du registre 
seront mis à zéro. 


Peut-étre que ca a été fait pour simplifier le portage du code sur x86-64. 


MUL multiplier sans signe. IMUL est souvent utilisée au lieu de MUL, en lire plus ici: 
11.1 on page 1287. 


NEG négation: op = -op La méme chose que NOT op / ADD op, 1. 


NOP NOP. Son opcode est 0x90, qui est en fait l'instruction sans effet XCHG EAX, EAX. 
Ceci implique que le x86 n'a pas d'instruction NOP dédiée (comme dans de nom- 
breux RISC). Ce livre contient au moins un listing oú GDB affiche NOP comme 
l'instruction 16-bit XCHG: 1.11.1 on page 68. 


Plus d'exemples de telles opérations: (.1.7 on page 1347). 


NOP peut étre généré par le compilateur pour aligner des labels sur une limite 
de 16-octets. Un autre usage trés répandu de NOP est de remplacer manuelle- 
ment (patcher) une instruction, comme un saut conditionnel, par NOP, afin de 
désactiver cette exécution. 
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NOT opl: op1 = -opl. inversion logique Caractéristique importante—l’instruction ne 
change pas les flags. 


OR «ou» logique 

POP prend une valeur depuis la pile: value=SS: [ESP]; ESP=ESP+4 (ou 8) 
PUSH pousse une valeur sur la pile: ESP=ESP-4 (ou 8); SS:[ESP]-value 
RET Revient d'une sous-routine: POP tmp; JMP tmp. 


En fait, RET est une macro du langage d'assemblage, sous les environnements 
Windows et *NIX, elle est traduite en RETN («return near») ou, du temps de 
MS-DOS, oü la mémoire était adressée différemment (11.7 on page 1297), en 
RETF («return far»). 


RET peut avoir un opérande. Alors il fonctionne comme ceci: 

POP tmp; ADD ESP opl; JMP tmp. RET avec un opérande termine en général 

les fonctions avec la convention d'appel stdcall, voir aussi: 6.1.2 on page 953. 
SAHF copier des bits de AH vers les flags CPU: 


7 6 4 2 0 


SFZF AF PF (CR 


Cette instruction est souvent utilisée dans du code relatif au FPU. 


SBB (subtraction with borrow) soustrait les valeurs, décrémente le résultat si le 
flag CF est mis. SBB est souvent utilisé pour la soustraction de grandes valeurs, 
par exemple: 


; fonctionne avec des valeurs 64-bit: soustrait val2 de vall. 

; .lo signifie les 32 bits les plus bas, .hi signifie les plus hauts. 

SUB vall.lo, val2.lo 

SBB vall.hi, val2.hi ; utilise CF mis à 1 ou 0 par l'instruction 
précédente 


Un autre exemple: 1.34 on page 509. 


SCASB/SCASW/SCASD/SCASQ (M) compare un octet/ un mot 16-bit/ un mot 32- 
bit/ un mot 64-bit stocké dans AX/EAX/RAX avec une variable dont l'adresse est 
dans DI/EDI/RDI. Met les flags comme le fait CMP. 


Cette instruction est souvent utilisée avec le préfixe REPNE: continue de scan- 
ner le buffer jusqu'à ce qu'une valeur particuliére stockée dans AX/EAX/RAX soit 
trouvée. D'oü le «NE» dans REPNE: continue de scanner tant que les valeurs 
comparées ne sont pas égales et s'arréte lorsqu'elles le sont. 


Elle est souvent utilisée comme la fonction C standard strlen(), pour déterminer 
la longueur d'une chaine ASCIIZ : 


Exemple: 

| Lea edi, string 

| mov ecx, OFFFFFFFFh ; scanne les octets 2?-1, i.e., presque 
l'infini . 

xor eax, eax ; 0 est le terminateur 


repne scasb 
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add edi, OFFFFFFFFh ; le corriger 
; maintenant EDI pointe sur le dernier caractére de la chaíne ASCIIZ. 


; déterminer la longueur de la chaîne 
; ECX vaut = -1-strlen 


not ecx 
dec ecx 


; maintenant ECX contient la longueur de la chaine 


Si nous utilisons une valeur différente dans AX/EAX/RAX, la fonction se com- 
porte comme la fonction C standard memchr(), i.e., elle trouve un octet spéci- 
fique. 


SHL décale une valeur à gauche 
SHR décale une valeur à droite: 


Ces instructions sont utilisées fréquemment pour la multiplication et la division 
par 2". Une autre utilisation trés fréquente est le traitement des champs de bits: 
1.28 on page 392. 


SHRD op1, op2, op3: décale la valeur dans op2 de op3 bits vers la droite, en prenant 
les bits depuis op1. 


Exemple: 1.34 on page 509. 


STOSB/STOSW/STOSD/STOSQ stocke un octet/ un mot 16-bit/ un mot 32-bit/ un 
mot 64-bit de AX/EAX/RAX à l'adresse se trouvant dans DI/EDI/RDI. 


Couplée avec le préfixe REP, elle est répétée en boucle, le compteur étant dans 
le registre CX/ECX/RCX: elle fonctionne comme memset() en C. Si la taille du 
bloc est connue lors de la compilation, memset() est souvent mise en ligne dans 
un petit morceau de code en utilisant REP MOVSx, parfois méme avec plusieurs 
instructions. 


memset(EDI, OxAA, 15) est équivalent à: 


; Sotcke 15 octets OxAA dans EDI 
CLD ; met la direction à en avant 
MOV EAX, OAAAAAAAAh 
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MOV ECX, 3 

REP STOSD ; écrit 12 octets 

STOSW ; écrit 2 octets de plus 
STOSB ; écrit l'octet restant 


(Apparemment, ca fonctionne plus vite que de de stocker 15 octets avec un 
seul REP STOSB). 


SUB soustrait des valeurs. Une utilisation fréquente est SUB reg, reg, qui met reg 
à zéro. 
TEST comme AND mais sans sauvegarder le résultat, voir aussi: 1.28 on page 392 


XOR op1, 0p2: XOR? valeurs. opl = op1@op2. Un schéma récurrent est XOR reg, reg, 
qui met reg à zéro. 


Instructions les moins fréquemment utilisées 


BSF bit scan forward, voir aussi: 1.36.2 on page 543 
BSR bit scan reverse 
BSWAP (byte swap), change le boutisme de la valeur. 
BTC bit test and complement 
BTR bit test and reset 
BTS bit test and set 
BT bit test 
CBW/CWD/CWDE/CDQ/CDQE Étendre le signe de la valeur: 
CBW Convertit l'octet dans AL en un mot dans AX 
CWD Convertit le mot dans AX en double-mot dans DX:AX 
CWDE Convertit le mot dans AX en double-mot dans EAX 
CDQ Convertit le double-mot dans EAX en quadruple-mot dans EDX:EAX 
CDQE (x64) Convertit le double-mot dans EAX en quadruple-mot dans RAX 


Cette instruction examine le signe de la valeur, l'étend à la partie haute de la 
valeur nouvellement construite. Voir aussi: 1.34.5 on page 521. 


Il est intéressant de savoir que ces instructions furent initialement appelées 
SEX (Sign EXtend), comme l'écrit Stephen P. Morse (un des concepteurs du CPU 
8086) dans [Stephen P. Morse, The 8086 Primer, (1980)]6 : 


The process of stretching numbers by extending the sign bit is 
called sign extension. The 8086 provides instructions (Fig. 3.29) to 


5eXclusive OR (OU exclusif) 
SAussi disponible en https://archive.org/details/The8086Primer 
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facilitate the task of sign extension. These instructions were initial- 
ly named SEX (sign extend) but were later renamed to the more 
conservative CBW (convert byte to word) and CWD (convert word 
to double word). 


CLD efface le flag DF. 

CLI (M) efface le flag IF. 
CLC (M) efface le flag CF 
CMC (M) bascule le flag CF 


CMOVcc MOV conditionnel: charge si la condition est vraie. Les codes condition sont 
les méme que l'instruction Jcc (.1.6 on page 1331). 


CMPSB/CMPSW/CMPSD/CMPSQ (M) compare un octet/ mot de 16-bit/ mot de 32- 
bit/ mot de 64-bit à partir de l'adresse qui se trouve dans SI/ESI/RSI avec la 
variable à l'adresse stockée dans DI/EDI/RDI. 


Avec le préfixe REP, elle est répétée en boucle, le compteur est stocké dans 
le registre CX/ECX/RCX, le processus se répétera jusqu'à ce que le flag ZF soit 
zéro (i.e., jusqu'à ce que les valeurs soient égales l'une à l'autre, d'oü le «E» 
dans REPE). 


Ca fonctionne comme memcmp() en C. 
Exemple tiré du noyau de Windows NT (WRK v1.2) : 


Listing 3 : base\ntos\rtl\i386\movemem.asm 


ULONG 
RtlCompareMemory ( 
IN PVOID Sourcel, 
IN PVOID Source2, 
IN ULONG Length 

) 


Routine Description: 


This function compares two blocks of memory and returns the number 
of bytes that compared equal. 


Arguments: 

Sourcel (esp+4) - Supplies a pointer to the first block of memory to 
compare. 

Source2 (esp+8) - Supplies a pointer to the second block of memory to 
compare. 


Length (esp+12) - Supplies the Length, in bytes, of the memory to be 
compared. 


Return Value: 
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; The number of bytes that compared equal is returned as the function 
; value. If all bytes compared equal, then the length of the original 


; block of memory is returned. 


RcmSourcel equ [esp+12] 
RcmSource2 equ [esp+16] 
RcmLength equ [esp+20] 


CODE_ALIGNMENT 
cPublicProc _RtlCompareMemory ,3 
cPublicFpo 3,0 


push esi 

push edi 

cld 

mov esi,RcmSourcel 
compare 

mov edi,RcmSource2 
compare 


; Compare dwords, if any. 


, 


rcm10: mov ecx,RcmLength 
shr ecx,2 
jz rcm20 
repe cmpsd 
jnz rcm40 


; Compare residual bytes, if any. 


, 


rcm20: mov ecx,RcmLength 
and ecx,3 
jz rcm30 
repe cmpsb 
jnz rcm50 
got 


; All bytes in the block match. 


, 


rcm30: mov eax,RcmLength 
pop edi 
pop esi 


StdRET _RtlCompareMemory 


save registers 


clear direction 
(esi) -> first block to 


(edi) -> second block to 


(ecx) = length in bytes 
(ecx) = length in dwords 
no dwords, try bytes 
compare dwords 


; mismatch, go find byte 


(ecx) = length in bytes 
(ecx) = length mod 4 


; 0 odd bytes, go do dwords 


compare odd bytes 


; mismatch, go report how far we 


set number of matching bytes 
restore registers 
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; When we come to rcm40, esi (and edi) points to the dword after the 
; one which caused the mismatch. Back up 1 dword and find the byte. 
; Since we know the dword didn't match, we can assume one byte won't. 


rcm40: sub esi,4 ; back up 
sub edi,4 ; back up 
mov ecx,5 ; ensure that ecx doesn't count 
out 
repe cmpsb ; find mismatch byte 


; When we come to rcm50, esi points to the byte after the one that 
; did not match, which is TWO after the last byte that did match. 


, 


rcm50: dec esi ; back up 
sub esi,RcmSourcel ; compute bytes that matched 
mov eax,esi ; 
pop edi ; restore registers 
pop esi ; 


StdRET _RtlCompareMemory 


stdENDP _RtlCompareMemory 


N.B.: cette fonction utilise une comparaison 32-bit (CMPSD) si la taille du bloc 
est un multiple de 4, ou sinon une comparaison par octet (CMPSB). 


CPUID renvoie des informations sur les fonctionnalités du CPU. Voir aussi: (1.30.6 
on page 475). 


DIV division non signée 
IDIV division signée 


INT (M) : INT x est similaire à PUSHF; CALL dword ptr [x*4] en environnement 
16-bit. Elle était énormément utilisée dans MS-DOS, fonctionnant comme un 
vecteur syscall. Les registres AX/BX/CX/DX/SI/DI étaient remplis avec les argu- 
ments et le flux sautait a l'adresse dans la table des vecteurs d'interruption 
(Interrupt Vector Table, située au début de l'espace d'adressage). Elle était ré- 
pandue car INT a un opcode court (2 octets) et le programme qui a besoin d'un 
service MS-DOS ne doit pas déterminer l'adresse du point d'entrée de ce ser- 
vice. Le gestionnaire d'interruption renvoie le contrôle du flux à l'appelant en 
utilisant l'instruction IRET. 


Le numéro d'interruption les plus utilisé était 0x21, servant une grande partie 
de on API. Voir aussi: [Ralf Brown Ralf Brown’s Interrupt List], pour les listes 
d'interruption plus exhaustives et d'autres informations sur MS-DOS. 


Durant l'ère post-MS-DOS, cette instruction était toujours utilisée comme un 
syscall à la fois dans Linux et Windows (6.3 on page 972), mais fût remplacée 
plus tard par les instructions SYSENTER ou SYSCALL. 


INT 3 (M) : cette instruction est proche de INT, elle a son propre opcode d'1 octet 
(0xCC), et est très utilisée pour le débogage. Souvent, les débogueurs écrivent 
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simplement l'octet OxCC à l'adresse du point d'arrêt à mettre, et lorsqu'une ex- 
ception est levée, l'octet original est restauré et l'instruction originale à cette 
adresse est ré-exécutée. 

Depuis Windows NT, une exception EXCEPTION BREAKPOINT est déclenchée lorsque 
le CPU exécute cette instruction. Cet événement de débogage peut étre inter- 
cepté et géré par un débogueur hóte, si il y en a un de chargé. S'il n'y en a pas 

de charger, Windows propose de lancer un des débogueurs enregistré dans le 
système. Si MSVS’ est installé, son débogueur peut être chargé et connecté 

au processus. Afin de protéger contre le reverse engineering, de nombreuses 
méthodes anti-débogage vérifient l'intégrité du code chargé. 


MSVC possède une fonction intrinsèque pour l'instruction:  debugbreak()?. 


Il y a aussi une fonction win32 dans kernel32.dll appelée DebugBreak()?, qui 
exécute aussi INT 3. 


IN (M) lire des données depuis le port. On trouve cette instruction dans les drivers 
de l'OS ou dans de l'ancien code MS-DOS, par exemple (8.8.3 on page 1105). 


IRET : était utilisée dans l'environnement MS-DOS pour retourner d'un gestionnaire 
d'interruption appelé par l'instruction INT. Equivalent à POP tmp; POPF; JMP 
tmp. 


LOOP (M) décrémente CX/ECX/RCX, saute si il est toujours non zéro. 


L'instruction LOOP était souvent utilisée dans le code DOS qui travaillait avec 
des dispositifs externes. Pour ajouter un petit délai, on utilisait ceci: 


MOV CX, nnnn 
LABEL: LOOP LABEL 


Le défaut est évident: le délai dépend de la vitese du CPU. 


OUT (M) encoie des données sur le port. L'instruction peut étre vue, en général, 
dans les drivers d'OS ou dans du vieux code MS-DOS, par exemple (8.8.3 on 
page 1105). 


POPA (M) restaure les valeurs des registres (R|E)DI, (RJE)SI, (R[E)BP, (RJE)BX, (R[E)DX, 
(RJE)CX, (RJEJAX depuis la pile. 


POPCNT population count. Compte le nombre de bits a 1 dans la valeur. 
POPF restaure les flags depuis la pile (AKA registre EFLAGS) 


PUSHA (M) pousse les valeurs des registres (R|EJAX, (R[E)CX, (R[E)DX, (RJE)BX, 
(RJE)BP, (R|E)SI, (R[E)DI sur la pile. 


PUSHF pousse les flags (AKA registre EFLAGS) 
RCL (M) pivote vers la gauche via le flag CF: 


"Microsoft Visual Studio 
8MSDN 
2MSDN 
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ROL/ROR (M) décalage cyclique 


ROL: rotation à gauche: 


En dépit du fait que presque presque tous les CPUs aient ces instructions, il n'y 
a pas d'opération correspondante en C/C++, donc les compilateurs de ces LPs 
ne générent en général pas ces instructions. 


Par commodité pour le programmeur, au moins MSVC fourni les pseudo-fonctions 
(fonctions intrinséques du compilateur) rotl() et rotr()!?, qui sont traduites di- 
rectement par le compilateur en ces instructions. 


SAL Décalage arithmétique à gauche, synonyme de SHL 


SAR Décalage arithmétique à droite 


De ce fait, le bit de signe reste toujours à la place du MSB. 


10MSDN 
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SETcc op: charge 1 dans l'opérande (octet seulement) si la condition est vraie et 


zéro sinon. Les codes conditions sont les méme que les instructions Jcc (.1.6 on 
page 1331). 


STC (M) met le flag CF 


STD (M) Met le flag DF. Cette instruction n'est pas générée par les compilateurs et 
est en général rare. Par exemple, elle peut étre trouvée dans le fichier du noyau 
de Windows ntoskrnl.exe, dans la routine de copie mémoire écrite à la main. 


STI (M) met le flag IF 

SYSCALL (AMD) appelle un appel systéme (6.3 on page 972) 
SYSENTER (Intel) appel un appel systéme (6.3 on page 972) 

UD2 (M) instruction indéfinie, léve une exception. Utilisée pour tester. 
XCHG (M) échange les valeurs dans les opérandes 


Cette instruction est rare: les compilateurs ne la génére pas, car à partir du Pen- 
tium, XCHG avec comme opérande une adresse en mémoire s'exécute comme 
si elle avait le préfixe LOCK ([Michael Abrash, Graphics Programming Black 
Book, 1997chapter 19]). Peut-étre que les ingénieurs d'Intel ont fait cela pour la 
compatibilité avec les primitives de synchronisation. Ainsi, à partir du Pentium, 
XCHG peut étre lente. D'un autre cóté, XCHG était trés populaire chez les pro- 
grammeurs en langage d'assemblage. Donc, si vous voyez XCHG dans le code, 
ca peut étre un signe que ce morceau de code a été écrit à la main. Toutefois, 
au moins le compilateur Borland Delphi génére cette instruction. 


Instructions FPU 


Le suffixe -R dans le mnémonique signifie en général que les opérandes sont inver- 
Sés, le suffixe -P implique qu'un élément est supprimé de la pile aprés l'exécution 
de l'instruction, le suffixe -PP implique que deux éléments sont supprimés. 


Les instructions -P sont souvent utiles lorsque nous n'avons plus besoin que la valeur 
soit présente dans la pile FPU aprés l'opération. 


FABS remplace la valeur dans ST(0) par sa valeur absolue 
FADD op: ST(0)=0p+ST(0) 
FADD ST(0), ST(i) : ST(0)=ST(0)+ST(i) 


FADDP ST(1)=ST(0)+ST(1); supprime un élément de la pile, i.e., les valeurs sur la 
pile sont remplacées par leurs somme 


FCHS ST(0)=-ST(0) 

FCOM compare ST(0) avec ST(1) 

FCOM op: compare ST(0) avec op 

FCOMP compare ST(0) avec ST(1); supprime un élément de la pile 
FCOMPP compare ST(0) avec ST(1); supprime deux éléments de la pile 
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FDIVR op: ST(0)=op/ST(0) 

FDIVR ST(i), ST(j) : ST(i)=ST(j)/ST(i) 

FDIVRP op: ST(0)=0p/ST(0); supprime un élément de la pile 

FDIVRP ST(i), ST(j) : ST(i)=ST(j)/ST(i); supprime un élément de la pile 
FDIV op: ST(0)=ST(0)/op 

FDIV ST(i), ST(j) : ST(i)2 ST(i)/ST(j) 


FDIVP ST(1)=ST(0)/ST(1); supprime un élément de la pile, i.e, les valeurs du divi- 
dende et du diviseur sont remplacées par le quotient 


FILD op: convertit un entier n et le pousse sur la pile. 
FIST op: convertit la valeur dans ST(0) en un entier dans op 


FISTP op: convertit la valeur dans ST(0) en un entier dans op; supprime un élément 
de la pile 


FLD1 pousse 1 sur la pile 

FLDCW op: charge le FPU control word (.1.3 on page 1327) depuis le 16-bit op. 
FLDZ pousse zéro sur la pile 

FLD op: pousse op sur la pile. 

FMUL op: ST(0)=ST(0)*op 

FMUL ST(i), ST(j) : ST(i)=ST(i)*ST(j) 

FMULP op: ST(0)=ST(0)*op; supprime un élément de la pile 

FMULP ST(i), ST(j) : ST(i)=ST(i)*ST(j) ; supprime un élément de la pile 
FSINCOS : tmp=ST(0); ST(1)=sin(tmp); ST(0)=cos(tmp) 

FSQRT : ST(0) = /ST(0) 


FSTCW op: stocker le mot de contrôle FPU (.1.3 on page 1327) dans l'op 16-bit 
après avoir vérifié s'il y a des exceptions en attente. 


FNSTCW op: stocker le mot de contrôle FPU (.1.3 on page 1327) dans l'op 16-bit. 


FSTSW op: stocker le mot d'état FPU (.1.3 on page 1327) dans l'op 16-bit après 
avoir vérifié s'il y a des exceptions en attente. 


FNSTSW op: stocker le mot d'état FPU (.1.3 on page 1327) dans l'op 16-bit. 
FST op: copie ST(0) dans op 

FSTP op: copie ST(0) dans op; supprime un élément de la pile 

FSUBR op: ST(0)=op-ST(0) 

FSUBR ST(0), ST(i) : ST(0)=ST(i)-ST(0) 


FSUBRP ST(1)=ST(0)-ST(1); supprime un élément de la pile, i.e., la valeur dans la 
pile est remplacée par la différence 
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FSUB op: ST(0)=ST(0)-op 
FSUB ST(0), ST(i) : ST(0)=ST(0)-ST(i) 


FSUBP ST(1)=ST(1)-ST(0); supprime un élément de la pile, i.e., la valeur dans la 
pile est remplacée par la différence 


FUCOM ST(i) : compare ST(0) et ST(i) 

FUCOM compare ST(0) et ST(1) 

FUCOMP compare ST(0) et ST(1); supprime un élément de la pile. 
FUCOMPP compare ST(0) et ST(1); supprime deux éléments de la pile. 


L'instruction se comporte comme FCOM, mais une exception est levée seule- 
ment si un opérande est SNaN, tandis que les nombres QNaN sont traités nor- 
malement. 


FXCH ST(i) échange les valeurs dans ST(0) et ST(i) 
FXCH échange les valeurs dans ST(0) et ST(1) 


Instructions ayant un opcode affichable en ASCII 


(En mode 32-bit.) 
Elles peuvent être utilisées pour la création de shellcode. Voir aussi: 8.14.1 on page 1178. 


caractére ASCII | code hexadécimal | instruction x86 
0 30 XOR 
1 31 XOR 
2 32 XOR 
3 33 XOR 
4 34 XOR 
5 35 XOR 
7 37 AAA 
8 38 CMP 
9 39 CMP 
: 3a CMP 
; 3b CMP 
< 3c CMP 
= 3d CMP 
? 3f AAS 
@ 40 INC 
A 41 INC 
B 42 INC 
C 43 INC 
D 44 INC 
E 45 INC 
F 46 INC 
G 47 INC 
H 48 DEC 
| 49 DEC 
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J 4a DEC 

K 4b DEC 

L 4C DEC 

M 4d DEC 

N 4e DEC 

O Af DEC 

P 50 PUSH 

Q 51 PUSH 

R 52 PUSH 

S 53 PUSH 

T 54 PUSH 

U 55 PUSH 

V 56 PUSH 

W 57 PUSH 

X 58 POP 

Y 59 POP 

Z 5a POP 

[ 5b POP 

\ 5c POP 

] 5d POP 

a 5e POP 

2 5f POP 

` 60 PUSHA 

a 61 POPA 

f 66 en mode 32-bit, change pour une 
taille d'opérande de 16-bit 

g 67 en mode 32-bit, change pour une 
taille d'adresse 16-bit 

h 68 PUSH 

i 69 IMUL 

j 6a PUSH 

k 6b IMUL 

p 70 JO 

q 71 JNO 

r 72 JB 

S 73 JAE 

t 74 JE 

u 75 JNE 

v 76 JBE 

w 77 JA 

x 78 JS 

y 79 JNS 

Z 7a JP 

De même: 


caractère ASCII 


code hexadécimal 


instruction x86 


1347 


f 66 en mode 32-bit, change pour une 
taille d'opérande de 16-bit 

g 67 en mode 32-bit, change pour une 
taille d'adresse 16-bit 


En résumé: AAA, AAS, CMP, DEC, IMUL, INC, JA, JAE, JB, JBE, JE, JNE, JNO, JNS, JO, JP, 
JS, POP, POPA, PUSH, PUSHA, XOR. 


.1.7 npad 


C'est une macro du langage d'assemblage pour aligner les labels sur une limite 
spécifique. 


C'est souvent nécessaire pour des labels trés utilisés, comme par exemple le début 
d'un corps de boucle. Ainsi, le CPU peut charger les données ou le code depuis la 
mémoire efficacement, à travers le bus mémoire, les caches, etc. 


Pris de listing.inc (MSVC) : 


Á propos, c'est un exemple curieux des différentes variations de NOP. Toutes ces 
instructions n'ont pas d'effet, mais ont une taille différente. 


Avoir une seule instruction sans effet au lieu de plusieurs est accepté comme étant 
meilleur pour la performance du CPU. 


;; LISTING.INC 


;; This file contains assembler macros and is included by the files created 
;; with the -FA compiler switch to be assembled by MASM (Microsoft Macro 
;; Assembler). 


;; Copyright (c) 1993-2003, Microsoft Corporation. All rights reserved. 


;; non destructive nops 
npad macro size 
if size eq 1 
nop 
else 
if size eq 2 
mov edi, edi 
else 
if size eq 3 
; lea ecx, [ecx+00] 
DB 8DH, 49H, 00H 
else 
if size eq 4 
; lea esp, [esp+00] 
DB 8DH, 64H, 24H, 00H 
else 
if size eq 5 
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add eax, DWORD PTR 0 
else 
if size eq 6 
; lea ebx, [ebx+00000000] 
DB 8DH, 9BH, 00H, 00H, 00H, 00H 
else 
if size eq 7 
; lea esp, [esp+00000000] 
DB 8DH, OA4H, 24H, 00H, OOH, OOH, OOH 
else 
if size eq 8 
; jmp .+8; .npad 6 
DB OEBH, 06H, 8DH, 9BH, 00H, OOH, 00H, 00H 
else 
if size eq 9 
; jmp .+9; .npad 7 
DB OEBH, 07H, 8DH, OA4H, 24H, 00H, OOH, OOH, OOH 
else 
if size eq 10 
; jmp .+A; .npad 7; .npad 1 
DB OEBH, 08H, 8DH, OA4H, 24H, OOH, OOH, OOH, OOH, 90H 
else 
if size eq 11 
; jmp .+B; .npad 7; .npad 2 
DB OEBH, 09H, 8DH, OA4H, 24H, OOH, OOH, OOH, OOH, 8BH, OFFH 
else 
if size eq 12 
; jmp .+C; .npad 7; .npad 3 
DB OEBH, OAH, 8DH, OA4H, 24H, 00H, 00H, OOH, OOH, 8DH, 49H, 00H 
else 
if size eq 13 
; jmp .+D; .npad 7; .npad 4 
DB OEBH, OBH, 8DH, OA4H, 24H, 00H, OOH, OOH, 00H, 8DH, 64H, 247 
V H, 00H 
else 
if size eq 14 
; jmp .+E; .npad 7; .npad 5 
DB OEBH, OCH, 8DH, 0A4H, 24H, OOH, OOH, OOH, OOH, 05H, OOH, > 
S 00H, OOH, OOH 
else 
if size eq 15 
; jmp .+F; .npad 7; .npad 6 
DB OEBH, ODH, 8DH, OA4H, 24H, OOH, OOH, OOH, OOH, 8DH, 9BH, 7 
& 00H, OOH, OOH, OOH 
else 
“out error: unsupported npad size 
.err 
endif 
endif 
endif 
endif 
endif 
endif 
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endif 

endif 
endif 
endif 
endif 
endif 
endif 
endif 
endif 
endm 


.2 ARM 


.2.1 Terminologie 


ARM a été initialement développé comme un CPU 32-bit, c'est pourquoi ici un mot, 
contrairement au x86, fait 32-bit. 


octet 8-bit. La directive d'assemblage DB est utilisée pour définir des variables et 
des tableaux d'octets. 


demi-mot 16-bit. directive d'assemblage DCW —"—. 
mot 32-bit. directive d'assemblage DCW —"—. 
double mot 64-bit. 

quadruple mot 128-bit. 


2.2 Versions 


ARMv4: Le mode Thumb mode a été introduit. 


ARMV6: Utilisé dans la lère génération d'iPhone, iPhone 3G (Samsung 32-bit 
RISC ARM 1176JZ(F)-S qui supporte Thumb-2) 


ARMv7: Thumb-2 a été ajouté (2003). Utilisé dans l'iPhone 3GS, iPhone 4, iPad 
lére génération (ARM Cortex-A8), iPad 2 (Cortex-A9), iPad 3ème génération. 


ARMv7s: De nouvelles instructions ont été ajoutées. Utilisé dans l'iPhone 5, 
l'iPhone 5c, l'iPad 4éme génération. (Apple A6). 


ARMv8: 64-bit CPU, AKA ARM64 AKA AArch64. Utilisé dans l'iPhone 5S, l'iPad 
Air (Apple A7). Il n'y a pas de mode Thumb en mode 64-bit, seulement ARM 
(instructions de 4 octets). 


.2.3 ARM 32-bit (AArch32) 

Registres d'usage général 
* RO — le résultat d'une fonction est en général renvoyé dans RO 
* R1...R12 — GPRs 
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* R13 — AKA SP (pointeur de pile) 
* R14 — AKA LR (link register) 
* R15 — AKA PC (program counter) 


RO-R3 sont aussi appelés «registres scratch » : les arguments de la fonctions sont 
d'habitude passés par eux, et leurs valeurs n'ont pas besoin d'étre restaurées en 
sortant de la fonction. 


Current Program Status Register (CPSR) 


Bit Description 

0..4 M — processor mode 

5 T — Thumb state 

6 F — FIQ disable 

7 | — IRQ disable 

8 A — imprecise data abort disable 
9 E — data endianness 

10..15, 25, 26 | IT — if-then state 

16..19 GE — greater-than-or-equal-to 
20..23 DNM — do not modify 

24 J — Java state 

27 Q — sticky overflow 

28 V — overflow 

29 C — carry/borrow/extend 

30 Z — zero bit 

31 N — negative/less than 


Registres VFP (virgule flottante) et registres NEON 


0..31P/5 | 32..64 | 65..96 | 97..127 
Qo! 8 bits 
D094 bits D1 
5032 bits | 51 S2 $3 


Les registres-S sont 32-bit, utilisés pour le stockage de nombre en simple précision. 
Les registres-D sont 64-bit, utilisés pour le stockage de nombre en double précision. 


Les registres-D et -S partagent le méme espace physique dans le CPU—il est possible 
d'accéder un registre-D via les registres-S (mais c'est insensé). 


De méme, les registres NEON sont des 128-bit et partagent le méme espace phy- 
sique dans le CPU avec les autres registres en virgule flottante. 


En VFP les registres-S sont présents: S0..531. 


En VFPv2 16 registres-D ont été ajoutés, qui occupent en fait le méme espace que 
S0..S31. 


En VFPv3 (NEON ou «SIMD avancé ») il y a 16 registres-D de plus, DO..D31, mais les 
registres D16..D31 ne partagent pas l'espace avec aucun autre registres-S. 
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En NEON ou «SIMD avancé » 16 autres registres-Q 128-bit ont été ajoutés, qui par- 
tagent le méme espace que DO..D31. 


.2.4 ARM 64-bit (AArch64) 

Registres d'usage général 

Le nombre de registres a été doublé depuis AArch32. 
* XO — le résultat d'une fonction est en général renvoyé dans X0 
* X0...X7 — Les arguments de fonction sont passés ici 
* X8 


* X9...X15 — sont des registres temporaires, la fonction appelée peut les utiliser 
sans en restaurer le contenu. 


e X16 
e X17 
e X18 


* X19...X29 — la fonction appelée peut les utiliser mais doit restaurer leurs va- 
leurs à sa sortie. 


* X29 — utilisé comme FP (au moins dans GCC) 
* X30 — «Procedure Link Register » AKA LR (link register). 


* X31 — ce registre contient toujours zéro AKA XZR ou ZR «Zero Register». Sa 
partie 32-bit est appelée WZR. 


* SP, n'est plus un registre d'usage général. 
Voir aussi: [Procedure Call Standard for the ARM 64-bit Architecture (AArch64), (2013)]*?. 


La partie 32-bit de chaque registre-X est aussi accessible par les registres-W (WO, 
W1, etc.). 


Partie 32 bits haute | Partie 32 bits basse 
XO 


WO 


.2.5 Instructions 


Il il y a un suffixe -S pour certaines instructions en ARM, indiquant que l'instruction 
met les flags en fonction du résultat. Les instructions qui n'ont pas ce suffixe ne 
modifient pas les flags. Par exemple ADD contrairement à ADDS ajoute deux nombres, 
mais les flags sont inchangés. De telles instructions sont pratiques à utiliser entre 
CMP où les flags sont mis et, e.g. les sauts conditionnels, où les flags sont utilisés. 
Elles sont aussi meilleures en termes d'analyse de dépendance de données (car 
moins de registres sont modifiés pendant leurs exécution). 


H Aussi disponible en http: //infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B _ 
aapcs64.pdf 
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Table des codes conditionnels 


Code Description Flags 

EQ Egal Z==1 

NE Non égal Z==0 

CS AKA HS (Higher or Same) | Retenue mise/ Non-signé, Plus grand que, égal | C == 1 

CC AKA LO (LOwer) Retenue a zéro / non-signé, moins que C==0 

MI moins, négatif / moins que N==1 

PL plus, positif ou zéro / Plus grnad que, égal N==0 

VS débordement V==1 

VC Pas de débordement V==0 

HI non signé supérieur / plus grand que C==1et 
Z==0 

LS non signé inférieur ou égal / inférieur ou égal C == 0 ou 
Z == 1 

GE signé supérieur ou égal / supérieur ou égal N==V 

LT signé plus petit que / plus petit que N!=V 

GT signé plus grand que / plus grnad que Z==0et 
N==V 

LE signé inférieur ou égal / moins que, égal Z==1ou 
N!2V 

None / AL toujours n'importe lequel 

.3 MIPS 


.3.1 Registres 


(Convention d 


'appel 032) 


Registres à usage général GPR 


Numéro Pseudonom | Description 
$0 $ZERO Toujours à zéro. Écrire dans ce registre est comme NOP. 
$1 SAT Utilisé comme un registre temporaire 
pour les macros assembleurs et les pseudo-instructions. 
$2 ...$3 $VO ...$V1 Le résultat des fonctions est renvoyé par ce registre. 
$4 ...$7 $AO ...$A3 Arguments de fonctions. 
$8 ...$15 $TO...$17 Utilisé pour des données temporaires. 
$16 ...$23 $50...$57 Utilisé pour des données temporaireu*. 
$24 ...$25 | $T8 ...$19 Utilisé pour des données temporaires. 
$26 ...$27 | $KO ...$K1 Réservé pour le noyau de l'OS. 
$28 $GP Pointeur global**. 
$29 $SP SP. 
$30 $FP FP"; 
$31 $RA RA. 
n/a PC PC. 
n/a HI Partie 32-bit haute d'une multiplication ou du reste d'une division***, 
n/a LO Partie 32-bit basse d'une multiplication ou du reste d'une division***. 
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Registres en virgule flottante 


Nom Description 

$FO..$F1 Le résultat d'une est renvoyé ici. 
$F2..$F3 Non utilisé. 

$F4..$F11 Utilisé pour des données temporaires. 
$F12..$F15 | Deux premiers arguments de fonction. 
$F16..$F19 | Utilisé pour des données temporaires. 
$F20..$F31 | Utilisé pour des données temporaires.*. 


* — L'appelée doit préservé le contenu. 
** — L'appelée doit préserver le contenu (sauf dans du code PIC). 
*** — Accessible en utilisant les instructions MFHI et MFLO. 


.3.2 Instructions 


Il y a 3 types d'instructions: 


* type-R: celles qui ont 3 registres, Les instructions-R ont habituellement la forme 
suivante: 


instruction destination, sourcel, source2 


Une chose importante à garder à l'esprit est que lorsque le premier et le se- 
cond registre sont les méme, IDA peut montrer l'instruction sous une forme 
plus courte: 


instruction destination/sourcel, source2 


Cela nous rappelle quelque peu la syntaxe Intel pour le langage d'assemblage 
x86. 


e type-I: celles qui ont 2 registres et une valeur immédiate 16-bit. 


* type-J: instructions de saut/branchement, elles ont 26 bits pour encoder l'offset. 


Instructions da saut 


Quelle est la différence entre les instructions -B (BEQ, B, etc.) et le -J (JAL, JALR, etc.)? 


Les instructions-B ont un type-l, ainsi, l'offset de l'instruction-B est encodé comme 
une valeur 16-bit immédiate. JR et JALR sont des types-R et sautent à une adresse 
absolue spécifiée dans un registre. J et JAL sont des type-J, ainsi l'offset est encodé 
en une valeur 26-bit immédiate. 


En bref, les instructions-B peuvent encoder une condition (B est en fait une pseudo- 
instruction pour BEQ $ZERO, $ZERO, LABEL), tandis que les instructions-] ne le peuvent 
pas. 
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.4 Quelques fonctions de la bibliothèque de GCC 


nom signification 

_ divdi3 | division signée 

. moddi3 | reste (modulo) d'une division signée 

_ udivdi3 | division non signée 

_ umoddi3 | reste (modulo) d'une division non signée 


.5 Quelques fonctions de la bibliothéque MSVC 


ll dans une fontion signifie «long long», i.e., type de donées 64-bit. 


nom signification 

. alldiv | division signée 

. alimut multiplication 

. allrem | reste de la division signée 

. allshl | décalage à gauche 

. allshr | décalage signé à droite 

. aulldiv | division non signée 

. aullrenm | reste de la division non signée 
. aullshr | décalage non signé à droite 


La multiplication et le décalage à gauche sont similaire pour les nombres signés et 
non signés, donc il n'y a qu'une seule fonction ici. 


Le code source des ces fonctions peut étre trouvé dans l'installation de MSVS, dans 
VC/crt/src/intel/*.asm. 


.6 Cheatsheets 
.6.1 IDA 


Anti-séche des touches de raccourci: 
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touche | signification 

Space | échanger le listing et le mode graphique 
convertir en code 

convertir en données 

convertir en chaíne 

convertir en tableau 

rendre indéfini 

donner l'offset d'une opérande 
transformer en nombre décimal 
transformer en caractére 

transformer en nombre binaire 
transformer en nombre hexa-décimal 
renommer l'identifiant 

calculatrice 

sauter à l'adresse 

; ajouter un commentaire 

Ctrl-X montrer les références à la fonction, au label, à la variable courant 
inclure dans la pile locale 


-Q-zounxriroc*»uo 


X montrer les références à la fonction, au label, à la variable, etc. 
Alt-l chercher une constante 

Ctrl-l chercher la prochaine occurrence d’une constante 

Alt-B chercher une séquence d’octets 

Ctrl-B chercher l'occurrence suivante d'une séquence d'octets 
Alt-T chercher du texte (instructions incluses, etc.) 

Ctrl-T chercher l'occurrence suivante du texte 

Alt-P éditer la fonction courante 

Enter sauter à la fonction, la variable, etc. 

Esc retourner en arriére 

Num- | cacher/plier la fonction ou la partie sélectionnée 


Num + | afficher la fonction ou une partie 


cacher une fonction ou une partie de code peut étre utile pour cacher des par- 
ties du code lorsque vous avez compris ce qu'elles font. ceci est utilisé dans mon 
script!?pour cacher des patterns de code inline souvent utilisés. 


.6.2 OllyDbg 


Anti-séche des touches de raccourci: 


raccourci | signification 

F7 tracer dans la fonction 
F8 enjamber 

F9 démarrer 

Ctrl-F2 redémarrer 


.6.3 MSVC 


. . Quelques options utiles qui ont été utilisées dans ce livre 


12GitHub 
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option | signification 

/01 minimiser l'espace 

/ObO pas de mire en ligne 

/Ox optimisation maximale 

/GS- désactiver les vérifications de sécurité (buffer overflows) 
/Fa(file) | générer un listing assembleur 

/Zi activer les informations de débogage 

/Zp(n) | aligner les structures sur une limite de n-octet 

/MD l'exécutable généré utilisera MSVCR* . DLL 


Quelques informations sur les versions de MSVC: 5.1.1 on page 908. 


.6.4 GCC 
Quelques options utiles qui ont été utilisées dans ce livre. 
option signification 
-Os optimiser la taille du code 
-03 optimisation maximale 
-regparm= nombre d'arguments devant étre passés dans les registres 
-o file définir le nom du fichier de sortie 
-g mettre l'information de débogage dans l'exécutable généré 
-S générer un fichier assembleur 
-masm=intel | construire le code source en syntaxe Intel 
-fno-inline ne pas mettre les fonctions en ligne 
.6.5 GDB 


Quelques commandes que nous avons utilisées dans ce livre: 
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option 


break filename.c:number 
break function 
break *address 

b 

p variable 

run 

r 

cont 

C 

bt 

set disassembly-flavor intel 
disas 

disas function 
disas function,+50 
disas $eip,+0x10 
disas/r 

info registers 

info float 

info locals 

X/W ... 

x/w $rdi 


x/10w ... 
X/S ... 

XJ ... 
x/10c ... 
x/b ... 

x/h ... 

x/g ... 
finish 
next 

step 

set step-mode on 
frame n 
info break 
del n 

set args ... 


mettre un point d'arrét à la ligne number du code source 


mettre un point d'arrét sur une fonction 
mettre un point d'arrét à une adresse 
afficher le contenu d'une variable 
démarrer 


n 


continuer l'exécution 

afficher la pile 

utiliser la syntaxe Intel 

disassemble current function 
désassembler la fonction 
disassemble portion 

désassembler avec les opcodes 
afficher tous les registres 

afficher les registres FPU 

afficher les variables locales 

afficher la mémoire en mot de 32-bit 
afficher la mémoire en mot de 32-bit 
à l'adresse dans RDI 

afficher 10 mots de la mémoire 
afficher la mémoire en tant que chaine 
afficher la mémoire en tant que code 
afficher 10 caractéres 

afficher des octets 

afficher en demi-mots de 16-bit 
afficher des mots géants (64-bit) 
exécuter jusqu'à la fin de la fonction 


instruction suivante (ne pas descendre dans les fonctions) 


instruction suivante (descendre dans les fonctions) 


ne pas utiliser l'information du numéro de ligne en exécutant pas à pas 


échanger la stack frame 
afficher les points d'arrét 
effacer un point d'arrét 


définir les arguments de la ligne de commande 


Acronymes utilisés 
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OS Système d'exploitation (Operating System)..................... xix 
POO Programmation orientée objet ............................ 700 
LP Langage de programmation ............................... xvi 
PRNG Nombre généré pseudo-aléatoirement ...................... x 
ROM Mémoire morte...................................... 111 
UAL Unité arithmétique et logique ............................. 36 
PID Dad BARS à 2 eut eo A ARA aa a REOR ee a 1054 
LF Line feed (10 ou Ari en C/C++)... 4 ea ee à de ga a a à à ee eS 675 
CR Carriage return (13 ou W' en C/C++)......................... 675 
LIFO Dernier entré, premier sorti.............................. 42 
MSB Bit le plus significatif . ................................. 407 


LSB Bit le moins significatif 
NSA National Security Agency (Agence Nationale de la Sécurité) ......... 1030 
CPB Cipher Feedback. uu oco ue haine AND e dee Dr res Lana 1119 


CSPRNG Cryptographically Secure Pseudorandom Number Generator (générateur 


de nombres pseudo-aléatoire cryptographiquement sûr)............ 1120 
ABI Application Binary Interface .............................. 22 
PC Program Counter. IP/EIP/RIP dans x86/64. PC dans ARM.............. 26 
SP pointeur de pile. SP/ESP/RSP dans x86/x64. SP dans ARM. ........... 26 


RA Adresse de retour ......... e ss 30 


PE Portable Executable à: 4058 SERA a S | x a Rem Ee ee 7 
DLL Dynamic-Link Library... css seed Rex ee ii 985 
LR Link Register. scs sese RR eR Eee ee 9 
IDA Désassembleur interactif et débogueur développé par Hex-Rays ...... 7 
IAT Import Address Table «sss o Rx cR mx xm Rx Ron EUR 986 
INT Import Name Table o e ca pe os ee ee ERR ERR 986 
RVA Relative Virtual Address................................. 986 
VA Virtual AdIBSE. «sucus ek EGRE RR AE NR ARR RR na ute 986 
OEP Original Entry Point: à 4 42 4 e 4 nsn gun mme; à @ doo mmn n Ree ed 971 


MSVC Microsoft Visual C++ 


MSVS Microsoft Visual Studio ................................ 1341 
ASLR Address Space Layout Randomization....................... 789 
MFC Microsoft Foundation Classes ............................. 991 
TUS Thread Local Storage oo. à lus de RR A un Rom Rn EE a 361 
AKA Also Known As — Aussi connu sous le nom de .................. 42 
CRT C Runtime IDEE oso sek mee Eun e EE Re |o GE me à OR RE 14 
CPU Central Processing UNIE : osse sk RR ERE REGE M RR SEE A xix 
GPU Graphics Processing Unit... .... aaa 1134 


FPU Floating-Point Unit < s s sa esc XR X haut Eos uo eS V 


CISC Complex Instruction Set Computing ........................ 27 
RISC Reduced Instruction Set Computing ........................ 3 
GUI Graphical User Interface................................. 981 
RTTI Run-Time Type Information .............................. 720 
BSS Block Started by Symbol wk kee eee a RR EE 35 
SIMD Single Instruction, Multiple Data .......................... 256 
BSOD Blue Screen of Death ...................,,...,,,..,... 972 
DBMS Database Management Systems ......................... 585 
ISA Instruction Set Architecture. ..........o ooo oo... . e... . . . . . .. xi 
HPC High-Performance Computing ............................. 664 
SEH Structured Exception Handling ............................ 52 


ELF Executable and Linkable Format: Format de fichier exécutable couramment uti- 


lisé sur les systèmes *NIX, Linux inclus ..................... 109 
TIB Thread Information Block . -o o ses 44 A eue E 361 
PIC Position Independent Code ............................... 693 
NAN Nota Number. 2244 sese zoe ur ass pe a 1328 
NOP piece à 4 Run Ha ae A 9 
BEQ (PowerPC, ARM) Branch if Equal ........................... 129 
BNE (PowerPC, ARM) Branch if Not Equal......................... 273 


BLR (PowerPC) Branch to Link Register .......................... 1083 


XOR eXclusive OR (OU exclusif). .....................,,,.,,... 1337 
MCU Microcontroller Unit... soos ha he Roh Rom dé ge 634 
RAM Random-Access Memory ................................ 4 
GCC GNU Compiler Collection … : 2 4 4 424 RE mRREG RR RR RERO 5 
EGA Enhanced Graphics Adapter .............................. 1298 
VGA Video Graphics Array : : . sssaaa aaa y 1298 
API Application Programming Interface .......................... 805 
ASCII American Standard Code for Information Interchange ............ 373 
ASCIIZ ASCII Zero ( chaîne ASCII terminée par un octet nul (à zéro) ....... 126 
1464 Intel Architecture 64 (Itanium) ............. RR RR 588 
EPIC Explicitly Parallel Instruction Computing ...................... 1294 
OOE Out-of-Order Execution ...................,.....,.,..,. 589 
MSDN Microsoft Developer Network............................ 794 
STL (C++) Standard Template Library........................... 729 
PODT (C++) Plain Old Data Type. ... ccc seo eee ee 745 


VM Virtual Memory (mémoire virtuelle) 
WRK Windows Research Kernel ............................... 932 
GPR General Purpose Registers ............................... 2 


SSDT System Service Dispatch Table ........................... 973 


RE Reverse Enginegring . : 4: 2.65568 octo mm A 1317 
BCD Binary-Coded Decimal ................................. 578 
BOM Byte Order Mark ..................................... 917 
GDB GNU Debugger . icc resa eR ua aa magma dame RS 67 
FP Frame POIS ECC T 33 
MBR Master Boot Record ................................... 925 
JPE Jump Parity Even (instruction x86) .......................... 308 
CIDR Classless Inter-Domain Routing ........................... 625 


STMFD Store Multiple Full Descending (instruction ARM) 


LDMFD Load Multiple Full Descending (instruction ARM) 


STMED Store Multiple Empty Descending (instruction ARM) ............ 43 
LDMED Load Multiple Empty Descending (instruction ARM)............. 43 
STMFA Store Multiple Full Ascending (instruction ARM) ............... 43 
LDMFA Load Multiple Full Ascending (instruction ARM)................ 43 
STMEA Store Multiple Empty Ascending (instruction ARM) ............. 43 
LDMEA Load Multiple Empty Ascending (instruction ARM).............. 43 
APSR (ARM) Application Program Status Register ................... 333 
FPSCR (ARM) Floating-Point Status and Control Register. .............. 333 


RFC Request for Comments ................................. 923 


TOS DEO Shack: AENA 857 
LVA (Java) Local Variable Array ............................... 865 
JVM Java Virtual Machine ................................... x 
JIT Just-In-Time compilation ................................. 855 
CDFS Compact Disc Fille System .. eek ee kn RES 939 


CD Compact Disc 


ADC Analog-to-Digital Converter .............................. 935 
EOP End of File (indé fichier) s à ae de a kk de Rugs Ro de de ee eA 118 
DIY DS IE Yourself Lie adress Rew ee babe delete des 799 
MMU Memory Management Unit .............................. 786 
DES Data Encryption Standard : 2.4 -o es ta oco eb dt RR hw 579 
MIME Multipurpose Internet Mail Extensions ...................... 579 
DBI Dynamic Binary Instrumentation ........................... 672 
XML Extensible Markup Language ............................. 811 
JSON JavaScript Object Notation .............................. 811 
URL Uniform Resource Locator ............................... 6 
IY IniGalestion VEGA econo a A Pee ee xii 
RSA Rivest Shamir Adleman ................................. 1237 


CPRNG Cryptographically secure PseudoRandom Number Generator ...... 1238 
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AES Advanced Encryption Standard ............................ 1278 
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IDE Integrated development environment ........................ 485 
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Glossaire 


anti-pattern En général considéré comme une mauvaise pratique. 45, 105, 588 


atomic operation «arouos » signifie «indivisible » en grec, donc il est garantie qu'une 
opération atomique ne sera pas interrompue par d'autres threads. 826, 1027 


basic block un groupe d'instructions qui n'a pas d'instruction de saut/branchement, 
et donc n'as pas de saut de l'intérieur du bloc vers l'extérieur. Dans IDA il res- 
semble à une liste d'instructions sans ligne vide. 896, 1298 


callee Une fonction appelée par une autre. 46, 65, 92, 118, 132, 135, 138, 544, 588, 
702, 841, 953, 955-957, 961, 962, 1353 


caller Une fonction en appelant une autre. 8-11, 14, 41, 65, 118, 132-134, 137, 
147, 206, 544, 601, 702, 953, 954, 956, 957, 962 


compiler intrinsic Une foncion spécifique d'un compilateur, qui n'est pas une fonc- 
tion usuelle de bibliothéque. Le compilateur génére du code machine spécifique 
au lieu d'un appel à celui-ci. Souvent il s'agit d'une pseudo-fonction pour une 
instruction CPU spécifique. Lire plus: (11.4 on page 1290). 1341 


CP/M Control Program for Microcomputers: un OS de disque trés basique utilisé 
avant MS-DOS. 1179 


dongle Un dongle est un petit périphérique se connectant sur un port d'imprimante 
LPT (par le passé) ou USB. Sa fonction est similaire au tokens de sécurité, il a 
de la mémoire et, parfois, un algorithme secret de (crypto-)hachage.. 1081 


décrémenter Décrémenter de 1. 26, 242, 266, 569, 942, 1331, 1335, 1341 
endianness Ordre des octets: 2.2 on page 586. 30, 108, 1337 

GiB Gibioctet: 2°° or 1024 mebioctets ou 1073741824 octets. 22 

incrémenter Incrémenter de 1. 23, 27, 242, 247, 266, 272, 420, 423, 569, 1331 


jump offset une partie de l'opcode de l'instruction JMP ou Jcc, qui doit étre ajoutée 
à l'adresse de l'instruction suivante, et c'est ainsi que le nouveau PC est calculé. 
Peut étre négatif. 127, 174, 175, 1331 


1366 


1367 
kernel mode Un mode CPU sans restriction dans lequel le noyau de l'OS et les 
drivers sont exécutés. cf. user mode. 1362 


leaf function Une fonction qui n'appelle pas d'autre fonction. 39, 45 


link register (RISC) Un registre oü l'adresse de retour est en général stockée. Ceci 
permet d'appeler une fonction leaf sans utiliser la pile, i.e, plus rapidemment. 
45, 1083, 1349, 1351 


loop unwinding C'est lorsqu'un compilateur, au lieu de générer du code pour une 
boucle de n itérations, génère juste n copies du corps de la boucle, afin de 
supprimer les instructions pour la gestion de la boucle. 245 


moyenne arithmétique la somme de toutes les valeurs, divisé par leur nombre. 
666 


name mangling utilisé au moins en C++, oü le compilateur doit encoder le nom 
de la classe, la méthode et le type des arguments dans une chaîne, qui devient 
le nom interne de la fonction. Vous pouvez en lire plus à ce propos ici: 3.21.1 
on page 699. 699, 909 


NaN pas un nombre: un cas particulier pour les nombres à virgule flottante, indi- 
quant généralement une erreur. 304, 326, 327, 1297 


NEON AKA «Advanced SIMD » — SIMD de ARM. 1350 


nombre réel nombre qui peut contenir un point. comme float et double en C/C++. 
285 


NOP «no operation », instruction ne faisant rien. 942 


NTAPI API disponible seulement dans la série de Windows NT. Trés peu documentée 
par Microsoft. 1038 


PDB (Win32) Fichier contenant des informations de débogage, en général seule- 
ment les noms des fonctions, mais aussi parfois les arguments des fonctions et 
le nom des variables locales. 908, 989, 1038, 1040, 1047, 1048, 1156 


pointeur de pile Un registre qui pointe dans la pile. 13, 15, 27, 42, 43, 49, 60, 75, 
77, 101, 135, 702, 841, 953, 955-957, 1325, 1332, 1349 


POKE instruction du langage BASIC pour écrire un octet à une adresse spécifique. 
943 


produit Résultat d'une multiplication. 133, 292, 296, 527, 559, 1287, 1288 
quotient Résultat de la division. 285, 288, 290, 291, 296, 558, 636, 668 


register allocator La partie du compilateur qui assigne des registes du CPU aux 
variables locales. 264, 395, 545 


reverse engineering action d'examiner et de comprendre comment quelque chose 
fonctionne, parfois dans le but de le reproduire. iv, 1340 


1368 
security cookie Une valeur aléatoire, différente à chaque exécution. Vous pouvez 
en lire plus à ce propos ici: 1.26.3 on page 358. 1015 


stack frame Une partie de la pile qui contient des informations spécifiques à la 
fonction courante: variables locales, arguments de la fonction, RA, etc.. 94, 133, 
610, 611, 1015 


stdout standard output, sortie standard. 29, 50, 206 


tail call C'est lorsque le compilateur (ou l'interpréteur) transforme la récursion (ce 
qui est possible: tail recursion) en une itération pour l'efficacité: wikipedia. 615 


tas Généralement c'est un gros bout de mémoire fournit par l'OS et utilisé par les ap- 
plications pour le diviser comme elles le souhaitent. malloc()/free() fonctionnent 
en utilisant le tas. 43, 447, 724, 727, 728, 745, 747, 768, 769, 812, 984, 986 


thunk function Minuscule fonction qui a un seul róle: appeler une autre fonction. 
31, 59, 504, 1083, 1095 


tracer Mon propre outil de debugging. Vous pouvez en lire plus à son propos ici: 
7.2.1 on page 1031. 248-250, 697, 793, 913, 928, 932, 933, 1009, 1075-1077, 
1159, 1167, 1172, 1173, 1176, 1192, 1289 


type de donnée intégral nombre usuel, mais pas un réel. peut étre utilisé pour 
passer des variables de type booléen et des énumérations. 301 


user mode Un mode CPU restreint dans lequel le code de toutes les applications 
est exécuté. cf. kernel mode. 1105, 1361 


Windows NT Windows NT, 2000, XP, Vista, 7, 8, 10. 373, 541, 840, 918, 973, 987, 
1026, 1183, 1340 


word Dans les ordinateurs plus vieux que les PCs, la taille de la mémoire était sou- 
vent mesurée en mots plutót qu'en octet. 577, 579-582, 732, 813 


xoring souvent utilisé en anglais, qui signifie appliquer l'opération XOR. 1015, 1098, 
1103 


Index 


.NET, 995 
OxOBADFOOD, 104 
OxCCCCCCCC, 104 


Ada, 144 
AES, 1116 
Alpha AXP, 3 
AMD, 960 
Angband, 389 
Angry Birds, 334, 335 
Anomalies du compilateur, 194, 386, 405, 
428, 630, 684, 1291 
Arbre binaire, 754 
ARM, 272, 948, 1082, 1349 
Addressing modes, 568 
ARM1, 583 
armel, 297 
armhf, 297 
Condition codes, 178 
D-registres, 295, 1350 
Data processing instructions, 639 
DCB, 27 
Fonction leaf, 45 
hard float, 297 
if-then block, 334 
Instructions 
ADC, 513 
ADD, 29, 143, 178, 251, 413, 428, 
639, 1351 
ADDAL, 178 
ADDCC, 229 
ADDS, 141, 513, 1351 
ADR, 26, 179 
ADRcc, 179, 215, 216, 589 
ADRP/ADD pair, 33, 76, 113, 368, 
387, 572 
ANDcc, 689 
ASR, 432 
ASRS, 405, 640 
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B, 75, 178, 180 

Bcc, 130, 131, 194 

BCS, 180, 337 

BEQ, 129, 216 

BGE, 180 

BIC, 404, 405, 411, 435 

BL, 26, 28, 30, 31, 33, 179, 573 

BLcc, 179 

BLE, 180 

BLS, 180 

BLT, 251 

BLX, 30 

BNE, 180 

BX, 140, 231 

CMP, 129, 130, 179, 216, 229, 251, 
428, 1351 

CSEL, 191, 197, 200, 429 

EOR, 411 

FCMPE, 337 

FCSEL, 337 

FMOV, 571 

FMRS, 413 

IT, 200, 334, 363 

LDMccFD, 179 

LDMEA, 43 

LDMED, 43 

LDMFA, 43 

LDMFD, 27, 43, 179 

LDP, 34 

LDR, 78, 101, 111, 346, 367, 568 

LDRB, 470 

LDRB.W, 273 

LDRSB, 272 

LEA, 589 

LSL, 428, 432 

LSL.W, 428 

LSLR, 690 

LSLS, 347, 412, 690 
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LSR, 432 Mode Thumb, 3, 180, 231 
LSRS, 412 Optional operators 

MADD, 141 ASR, 428, 639 

MLA, 140 LSL, 346, 381, 428, 571 
MOV, 11, 27, 29, 428, 639 LSR, 428, 639 

MOVcc, 194, 200 ROR, 428 

MOVK, 571 RRX, 428 

MOVT, 29, 639 Pipeline, 229 

MOVT.W, 30 Registres 

MOVW, 30 APSR, 333 

MUL, 143 FPSCR, 333 

MULS, 141 Link Register, 26, 27, 45, 75, 231, 
MVNS, 273 1349 

NEG, 649 RO, 145, 1349 

ORR, 404 scratch registers, 273, 1349 
POP, 26-28, 42, 45 X0, 1350 

PUSH, 28, 42, 45 Z, 129, 1350 


RET, 34 
RSB, 186, 381, 428, 649 


S-registres, 295, 1350 
soft float, 297 


SBC, 513 ARM64 

SMMUL, 639 lo12, 76 

STMEA, 43 ASLR, 987 

STMED, 43 AWK, 930 

STMFA, 43, 80 

STMFD, 26, 43 Base address, 986 

STMIA, 78 base32, 921 

STMIB, 80 Base64, 920 

STP, 33, 76 base64, 923, 1112, 1239 

STR, 77, 346 base64scanner, 920 

SUB, 77, 381, 428 bash, 146 

SUBcc, 689 BASIC 

SUBEQ, 274 POKE, 942 

SUBS, 513 BeagleBone, 1128 

SXTB, 471 Bibliothéque standard C 

SXTW, 387 alloca(), 49, 364, 588, 1003 

TEST, 264 assert(), 371, 924 

TST, 397, 428 atexit(), 731 

VADD, 296 atoi(), 641, 1142 

VDIV, 296 close(), 978 

VLDR, 295 exit(), 601 

VMOV, 295, 333 fread(), 808 

VMOVGT, 333 free(), 588, 589, 769 

VMRS, 333 fwrite(), 808 

VMUL, 296 getenv(), 1144 

XOR, 187, 413 localtime(), 852 
Mode ARM, 3 localtime_r(), 457 


longjmp, 814 
longjmp(), 206 
malloc(), 448, 588, 769 


Mode switching, 140, 231 
mode switching, 30 
Mode Thumb-2, 3, 231, 334, 336 
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memchr(), 1335 
memcmp(), 586, 659, 926, 1338 
memcpy(), 17, 92, 656, 812, 1333 
memmove(), 812 
memset(), 340, 654, 1172, 1336 
open(), 978 
pow(), 298 
puts(), 29 
qsort(), 495, 600 
rand(), 436, 912, 1045, 1047, 1074, 
1110 
read(), 808, 978 
realloc(), 588 
scanf(), 91 
setjmp, 814 
srand(), 1074 
strcat(), 660 
strcmp(), 586, 600, 651, 978 
strcpy(), 17, 654, 1111 
strlen(), 263, 539, 653, 677, 1335 
strstr(), 599 
strtok, 277 
time(), 852, 1074 
toupper(), 686 
va_arg, 666 
va_list, 671 
vprintf, 671 
write(), 808 
binary grep, 928, 1030 
Binary Ninja, 1030 
BIND.EXE, 994 
BinNavi, 1030 
binutils, 489 
Binwalk, 1230 
Bitcoin, 822, 1128 
Boehm garbage collector, 797 
Boolector, 58 
Booth's multiplication algorithm, 284 
Borland C++, 784 
Borland C++Builder, 909 
Borland Delphi, 20, 909, 915, 1343 
BSoD, 972 
BSS, 988 
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